Clusters, which allowed large companies’ super-administrators to group customer numbers and installation numbers and then assign S-users authorizations on this level, are being phased out. All customers are encouraged to use the new Authorization Packages feature instead, which is more powerful and benefits companies of all sizes. To avoid data inconsistencies, S-users who in the past got authorizations assigned on cluster level should get these permissions amended.
Over the past few years, since its general availability in February 2016, the SAP ONE Support Launchpad and its applications have replaced traditional SAP support tools with modern alternatives. Right from the start, the focus of the launchpad development was not on copying existing functionality, but on questioning technical processes and adapting them wherever it makes sense.
Now, SAP Support is about to retire one of the few remaining legacy applications on the service.sap.com (SAP Service Marketplace) infrastructure, Cluster Maintenance. The feature replacing it, Authorization Packages, has been developed in close collaboration with our customers. It enables you to accomplish user management-related tasks with increased ease and efficiency.
However, the underlying concept is different from clusters, hence some groundwork needs to be completed.
What is a cluster?
Authorization management for your company’s S-user IDs deals with permissions (“authorization objects”) that are required to fulfill certain support-related tasks, for instance report incidents.
Most authorizations can be limited to selected installations, customer numbers or other so-called “authorization levels” at which the user can exercise this right.
Example: A user may be allowed to report incidents for one particular SAP product that your company has licensed (represented by an installation), but not for others.
The Cluster Maintenance feature allows you to group certain customer numbers, installation numbers, CCoE numbers and/or individual user IDs: you define “clusters”, your very own authorization levels. Subsequently, authorizations (like Report an Incident) can be granted to users on these clusters. The feature is mainly intended for customers with many installations and customer numbers.
And authorization packages?
Well, clusters are neither fish nor fowl: They only cover one aspect of granting authorizations, the level, but completely ignore permissions for the task. Authorization packages eliminate this functional shortcoming: User administrators can define a very specific authorization profile and reuse this “branding iron” over and over again. For instance, you can bundle some incident management-related authorizations like Report an Incident and Close Incidents for one of your subsidiaries – that’s a customer number – in a package Demo Company Argentina Helpdesk. If a new colleague joins the Argentinian IT team, simply apply this package to his user ID, thus adjusting his profile with one click.
Transition from clusters to authorization packages
By now you will have a better understanding of the two similar, but still different concepts. Unfortunately, there is no way to migrate clusters to authorization packages. Therefore, some manual work is required.
Step 1: Draft a blueprint for your S-user authorizations.
Are there colleagues in your company that share a huge part of their authorization profiles? If yes, using authorization packages will simplify user administration. You should then proceed to …
Step 2: Define authorization packages and apply them to these users.
Step 3: Identify users with permissions on cluster level and correct their profile
You know these colleagues? Great, then please go ahead and delete all authorizations that had been granted on cluster level. If not, SAP Support is able to assist and share a list of these user IDs with you. Even better: If you give your approval, SAP will remove all authorizations that were granted on cluster level from the authorization profiles of all your users. See below for further details.
A word of caution: You might be tempted to skip this clean-up step. But once the Cluster Maintenance application gets retired, these users will have “zombie” authorizations on some bizarre bundles of installation and customer numbers – you wouldn’t even know which ones! – that cannot be maintained anymore.
Almost inevitably, data inconsistencies will be the result.
Eventually, towards the end of this year, support applications will ignore authorizations on cluster levels. Which means that, unless you have corrected their profiles, many of your colleagues would lose their ability to complete important support tasks.
Step 4 (optional): Delete obsolete clusters.
Once a cluster is not assigned to any user, super-administrators can delete it using the Cluster Maintenance legacy application: From the list of all clusters, select the one you want to get rid of, enter the Edit mode, and click the Delete button.
So, what’s next?
With our Wave 4/2018 release for support applications on May 26th, creating new clusters and changing existing ones has been disabled.
Though you can still grant users authorizations on existing clusters, it goes without saying that you should stop using clusters straightaway; the new authorization packages feature is powerful and mature enough to replace clusters. Every new cluster assignment will cause unnecessary work.
Starting with the next release, Wave 5/2018 on July 5th, it will no longer be possible to assign authorizations on cluster levels. Furthermore, SAP will start alerting user administrators, and a launchpad-internal notification will be shown if authorization profiles of users in their company still have references to clusters.
Towards the end of 2018, the Cluster Maintenance application shall be retired.
How does SAP assist?
Most customers won’t require any help; in their company, the feature is hardly used, if at all.
However, if you have defined clusters and used them extensively to grant users authorizations, it can indeed become difficult to identify these colleagues, and tedious to clean up their profiles. We are here to help.
- SAP can share a list of all users that have got authorizations granted on cluster level with you. User administrators can simply report an incident under component XX-SER-SAPSMP-USR, subject “Users with authorizations on clusters”, and include the customer number of the users.
- Based on that list, SAP can remove all authorizations granted on cluster level from the affected user IDs. If you are interested in this service, report an incident under component XX-SER-SAPSMP-USR, subject “Remove all authorizations on cluster level from all user profiles”.Please note that it is not possible to exclude specific entries from the list. For all users, SAP will remove all authorizations that were granted on any cluster level. Regardless of the user, regardless of the cluster, regardless of the authorization object.
- Finally, if you’d like to use authorization packages to maintain your users’ profiles and want a particular package being applied to many users (let’s say more than one hundred), SAP can do this for you as well: First, create the authorization packages and a list of all user IDs they shall be applied to. Then, report an incident under component XX-SER-SAPSMP-USR, subject “Assign authorization packages to users”, and attach the list. It should be in XLS format and contain two columns, one for the name of the authorization package, the second one for all user IDs the package shall be assigned to.
Piloting Program SAP ONE Support Launchpad
We invite interested customers and partners to a special piloting program for the SAP ONE Support Launchpad. In this program, we offer roll-out and feedback sessions. We present new functionality that has become available since the previous release; give an outlook and insight on what we are currently working on; and collect and discuss feedback and ideas with participants. Sessions are held every 6-8 weeks. All interested parties can participate without obligations. The only prerequisite is a valid Feedback Agreement with SAP.
In case you would like to be involved and invited to future sessions, simply send an e-mail to my colleague Arno Helmling containing your name, S-user