Skip to Content
Author's profile photo Julie Plummer

NWBC, Roles, and Finding UI Innovations

or: What a customer and partner taught me about NWBC

NL for Business i.s.o. (NL4B) are an experienced implementation partner. Customers include Deloitte and Oxfam. TheUniversity of Leiden is the Netherlands’ oldest and one of their most prestigious universities. (Queen Beatrix is a graduate). In session CD120 in Amsterdam, they discussed their experiences developing a proof of concept with SAP NetWeaver Business Client. The speakers were: Robert Eijpe of NL for Business i.s.o. NL4B, and Peter
Magielse of Universiteit Leiden.

For me the biggest revelation was how they use roles. One of the questions I get asked most often is: “How can I find and utilize new content in an EHP?” OR “I know there are lots of POWLs, FPM applications etc available, but where the heck are they?”

The NL4B answer is simple and effective: Pick an area – a line of business, or an industry – , then pick a typical user – eg Accounts Receivable for Financials. There will probably be a role available for this or a similar user. In this case, there is: SAP_AIO_AR_CLERK-S = Accounts Receivable. In fact,
SAP delivers about 130 sample roles, which I have documented SCN: Sample Roles .

When you open the role in PFCG, you can see the FPM / WDA/ POWL applications – appropriate for that user. I had been wondering about a similar  approach for some time, but it turns out NL4B are practising this approach with real customers, with very positive results.

What you can also do, and which NL4B did, is copy a pre-delivered SAP role and use it as a template, adding your own content. As they pointed out, this lets you provide your users with a painless transition – you include traditional, SAP GUI transactions; plus new FPM or UI5-based SAP applications; plus NW Portal iViews; plus third-party content.

Another advantage that hadn’t occurred to me at all is that consultants often offer to custom build something that is actually available out of the box, or
with a slight tweak. eg if a consultant promises to build a custom report, you may find an existing POWL that does the job already.

OK, what else did I learn?

Personal Object Worklists (POWLs) are push-based lists of objects that the user must deal with, and support personal queries – eg Open Purchase Orders.

Runbook is a SAP add-on, used by Leiden University for monthly closing. They chose it for the first personalized landing pages, because it is already familiar to end users.

More info here: Runbook

Side Panels

NL4B confirmed what we always hoped: Side panels really do provide users with additional information, which saves them jumping from screen to screen,
lets them work much faster with fewer errors – and consequently cuts costs for the enterprise/ organization.
This last part is obvious, but I hadn’t thought of it till then.

The University said that Master Data Details; Notes and Attachments; and Charts added the most value to users. NL4B also provided Leiden University with
a custom side panel, displaying an invoice (for the customer displayed in the main SAP GUI transaction). This, and the custom button on a POWL, were the only custom-built content – everything else they showed was out of the box.


Peter of Leiden University summed up:

  • “POWLs and Side Panels definitely improve the way of working
  • Integration of different sources is useful for single point of access
  • Search possibility and pinning[of tabs] are quick wins during implementation”

He also said that the process had definitely been worth while, since user experience is “much better than it was, especially using side panels”. Also, implementation takes less time than expected – ie days, not weeks, because so much is available out of the box.

NL4B summarized their lessons learned:

  •   NWBC must be treated as a portal
    • Content comes from different sources
    • Security, authentication, and authorization must be in place in your project
  • Split your roles for maintenance reasons
    • Generic NWBC authorizations
    • Specific NWBC menu and authorization and Specific NWBC side panel menu and authorization
  • Start implementing role by role based on new requirements
    • Take time to roll out new functionality
  • Manage the change and explain the value
    • People trust and love their good old SAPGui

My summary: I learned loads about how NWBC is used with the Business Suite in real life. Many thanks to NL4B and Universiteit Leiden for all their hard work.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Simon Kemp
      Simon Kemp

      Hi Julie,

      Thanks for sharing this. Can you elaborate on the following:

      • Split your roles for maintenance reasons
      • Generic NWBC authorizations
      • Specific NWBC menu and authorization and Specific NWBC side panel menu and authorization

      It sounds important, but I don't really understand what you mean.



      Author's profile photo Julie Plummer
      Julie Plummer
      Blog Post Author

      Hi Simon,

      This statement actually came directly from the talk, so rather than my spin on it, I have asked the speaker to elaborate. I'll let you know as soon as I hear back.

      Best wishes;

      Author's profile photo Manuel Herr
      Manuel Herr

      Hi Simon,

      i think they split up roles which provide the user only with a menu and roles which have authorizationobjects inside.

      e.g. our nwbc role RMACLERKS contains only the role menu

      It contains no authorizations objects (only a informational SiAM object)

      A user which has only this role assigned, is able to log on in nwbc and will get a menu,

      but he is not able to start any tranaction.

      Within this logic you are able to provide the same menu to users which are able to do different things e.g. display only or change data.



      Author's profile photo Simon Kemp
      Simon Kemp

      Ah OK Manuel... I see what you mean. You split the Menu (what the user sees) from the authorizations (what the user can actually do) into different roles. You essentially have "Menu Roles" and "Authorization Roles" and any given user must have both to be able to work.


      I am very interested in how others manage the NWBC roles and what could be considered "Best Practice" and avoid a lot of manual work.

      Author's profile photo Former Member
      Former Member

      So it seems that the SAP recommendation is splitting the NWBC Menu and NWBC authorizations.

      What are companies supposed to do with existing traditional SAP GUI roles?

      Author's profile photo Simon Kemp
      Simon Kemp

      Hi Lasse

      You can continue to use existing GUI roles but filter them out of the NWBC menu by using a cockpit for NWBC.



      Author's profile photo Former Member
      Former Member

      When we're talking about a migration from SAP GUI to NWBC, hiding the existing GUI roles would leave most users out in the cold, not having their User menu in NWBC.

      Are you suggesting to create and use Cockpits exclusively for NWBC? E.g. add Single Roles and Composite roles to the cockpits and just use cockpits?

      Author's profile photo Simon Kemp
      Simon Kemp

      The GUI user menu is always still available via SMEN. If you already have well defined menus then by all means continue to use them in NWBC. You don't have to split menus from authorisations (this debate continues).

      Cockpits are just a handy way to filter menus.

      Author's profile photo Former Member
      Former Member

      Good point, and yes, this is indeed an ongoing debate. If you've worked with Portals before, your view is probably that Content roles and Auth. roles should be separated.