Control user permissions in SAP PCM

Most businesses have employees in different roles, like purchasing, production process, sales and marketing employees. When implementing an SAP Commerce solution like SAP PCM you should take those roles into account. How do you control which products your employee can see or edit? In this blog I want to take a quick dive into the possibilities of how to handle user permissions within SAP PCM.

User permissions should help improve data quality and integrity. Users with the right expertise should only edit certain properties. Data that is privacy sensitive should probably be hidden for certain users. Out of the box SAP Commerce contains some basic tools to configure permissions like user-rights and search-conditions. With custom implementation it is also possible to set a default filter on search results provided by the search engine like Solr or set permissions based on an object status.

User rights

The easiest way to configure which objects and properties a user may see or change, is called user rights configuration. In this configuration a user or a user-group can be granted permission to read, write, add or delete an object. It is also possible to configure permissions on individual property level, for example: an employee may change the description of a product but is prohibited to add a new price to the product.

User rights are easily maintainable from the SAP Commerce Backoffice by a system admin on user or user-group level. Often this configuration is embedded in the deployment process to ensure that all user-permissions are correct at any time.

This configuration applies to an object or property in general. It is not possible to change permissions dynamically based on object state. If a user cannot edit the name of a product based on the user permissions scheme, this user cannot change the name of any product.

Dynamic user permissions

Permissions are not always black or white. In many cases there is also a grey area. The preferred permissions for the same property can change depending on the object state.

A frequently heard example is whether a user should be able to change a price with a startdate in the past. A common practice should be that a price can be modified until the price starts but should be read-only after this start-date. This cannot be configured by basic user-rights configuration but should be determined dynamically.

It is possible to add a dynamic user permission like the price example above, but this needs to be done programmatically. In a SAP Commerce project, it is possible to grant read, write, add and delete permissions to the current object based on the given object state. Implementing dynamic user permissions gives huge flexibility in determining the right permissions for the given user.

Search restrictions

Another powerful but basic tool is search conditions. These conditions can be set up per user or user-group and add an extra condition to the search query for the given type.

Let’s say that you have a Boolean property on product that indicates if the given product is discontinued and you do not want to show these products to certain employees. Then you can add a search restriction on product that filters all products that have the value discontinued=true for this user-group. The product still exists in your database, but the users of the given user-group cannot see these products anymore.

Restrict filtering and search results

SAP PCM mainly relies on Solr for fast searching and filtering of the given search results. Solr is a search engine that can search and filter results extremely fast. When a product is found, the additional data will be retrieved from the regular database. Just like the example above you would only like to show relevant products to your user. Initially Solr returns all search results based on your search criteria and does not consider any search restrictions or user-right permissions.

Suppose you want to remove the discontinued products from the example above out of the Solr result. It is possible to add a default hidden filter to Solr to create a sub selection of items before Solr returns the results, like discontinued=false. This filter should remove all discontinued products from the result set. A condition is that the filtered property should be indexed by Solr.

An initial filter should be added programmatically to SAP Commerce and cannot be configured. This filter will not be shown in the available filters list and only results with this default filter will be shown. An important note is that these initial Solr filters are solely for filtering out search results and do not filter actual database results. That is why these filters are not completely reliable and should always be implemented with an additional search-condition or user permissions.

Conclusion

SAP Commerce provides a lot of tools to define user permissions. The tools described in this blog are the most common way to deal with user permissions.

The basic tools like general user permission settings and search restrictions are easily configurable without the need of writing any code. When permissions should be based on object state or when the Solr results should be filtered in advance some coding is necessary. Fortunately, it is easy to add custom logic to SAP Commerce and create complex user permission schemes based on your company’s needs.