Improved Authorization Concept for Business Rules with 1H 2025 Release

[Sylvia_Strangfeld]

Motivation and Transition to Enhanced Authorization

Managing permissions effectively within business rules is increasingly important for our customers. To address their customer feedback and enhance control over business rules , we are launching an upgrade to our authorization concept for working with business rules with 1H 2025.

Previously, the "Metadata Framework → Configure Business Rules" permission was too broad, making it impossible to differentiate between viewing and editing rules, or restricting access to rules for specific applications, such as time management.

Leveraging Role-Based Permissions (RBP), the new concept provides the necessary granularity and ensures users gain precise access, allowing them to manage rules only within their authorized business areas. This enhances security and operational efficiency. Having said that, let's look into the details.

How does it work? - Setting up the correct configuration to use RBP for the business rules object

When working with a secured business rule object, it's essential to ensure proper maintenance and configuration.

The following steps are needed to secure your business rule object effectively and ensure system integrity.

Maintain the Security Settings of the Business Rule Object

To secure the business rule object, you must maintain its "Security" section within the Configure Object Definition.

Step 1: Ensure that you apply the following MANDATORY configurations:

• Secured: Set this value to "Yes" to ensure the business rule object is protected.
• CREATE Respects Target Criteria: Set this value to "YES", too. This is requested by MDF to ensure that the specified target criteria will be respected in a create operation as well. 

Step 2: Optional, but recommended → Assigning a Permission Category

• Permission Category: Select the "Business Rules Object Permissions" value. This makes it easier to find the business rule object in the “Manage Permission Roles” page.
• If you do not select a permission category, the business rule object is added to the “Miscellaneous Permissions” category by default. From a functional perspective, this doesn’t make any difference. However, we recommend using the “Business Rules Object Permissions” category for more efficiency.

If the business rule object is correctly secured, the necessary permissions need to be granted. For existing customers, this means that the permission roles need to be updated. You can find the permission roles that already grant permissions to work with business rules by using our new Check Tool check. I’ll describe that a bit later.

Grant Permissions to Work With Business Rules

When the business rule object is secured, it is essential to grant the appropriate permissions to users. Two mandatory (and one optional) permissions are required, based on the intended level of access for users.

Mandatory Permissions

• Administrator Permissions → Metadata Framework → "Configure Business Rules": This foundational permission must continue to be granted, as it was required prior to implementing the new concept.
  

• Administrator Permissions → Business Rules Object Permissions (or User Permission → Miscellaneous Permissions): These new permissions must be correctly configured to provide View or Edit access. If you didn't follow our initial recommendation regarding the permission category, these are placed in the miscellaneous permission category.
   

ATTENTION! Understanding the Differences

Unlike other MDF objects, the Business Rules Object permissions deviate from standard time-dependent object permission behaviors. Though specific, granular actions can be assigned to time-dependent MDF objects, these are not applicable for a configuration object such as the business rule object; hence, we simplify permissions by distinguishing between only View and Edit.

• View Permissions:
  Ensure both view actions, View Current and View History, are selected for roles meant to have just View access.
• Edit Permissions:
  Since Edit encompasses View, both view permissions must be flagged alongside all edit actions: Create, Insert, Correct, Delete. Should any action be missing, such as forgetting to flag View History, the system will not grant view access. Rest assured, the Check Tool will highlight these misconfigurations, which I will detail shortly.

Optional Permissions

To fine-tune authorization further, you may apply restrictions by setting Target Criteria in the Role Assignment. This allows specifying access to particular business areas, like granting Onboarding Business Admin permissions by selecting all Onboarding Scenarios.

What to expect? - What will be impacted by the new authorizations?

When the business rule object is secured and configured with Role-Based Permissions, it significantly impacts various areas in the system.

Let’s dig into the details.

Business Rules Admin Page (List of Business Rules)

The Business Rules Admin page is the central entry point to work with business rules.

It provides a list of all rules that exist in the system. If the business rule object is secured, it can only be accessed if the user has the Configure Business Rules permission + (at least) View permission for the Business Rule object.

Unlike view and edit permissions, certain functionalities are not offered when only the view permission is granted. This includes:

• The “Create New Rule” button
• The “Delete” button

If Edit & View or just View permissions are granted and, additionally, target criteria are restricted to certain scenarios, then:

• The result list will only show rules based on these allowed scenarios.
• If the user selects an unauthorized scenario via the Scenario filter in the filter bar, the result list will not show any rule for that scenario, even if some exist.
• Instead, the user will see a message that no data is available, or the necessary permission is missing.

Configure Business Rules page

Also, the Configure Business Rule page doesn’t offer certain functionalities if the user has view permissions only, which includes:

• Change Scenario: As changing the scenario changes the rule configuration, it is not offered.
• Insert New Record & Create New Rule: Neither button appears on the UI.
• Take Action menu with the actions Make Correction, Copy Rule & Permanently Delete Entry: These actions are covered by the edit permissions and not offered when only View is granted.

The only available action in the Take Action Menu that might be available if the user has just view permission is the Add to Transport Bundle action. This is a separate permission and not covered by the business rule object permissions at all.

Rule Assignment in Application Configuration

Efficient rule assignment is facilitated within most of our applications UIs, offering intuitive ways to manage and engage with business rules.

Several UIs, such as the Manage Business Configuration UI in the screenshot below, feature options to create new rules (“+” icon) or view assigned rules (“Quick Card” icon) through a streamlined link to the Business Rules Framework, ensuring users have immediate access.

With the new authorization concept, these UIs react according to the granted permissions of the users.

The application UIs also react to the defined target criteria. For assigning rules, the field value help offers the list of rules that are allowed to be assigned, based on the rule scenario. If the user's role hasn’t been granted access to the expected scenario, the drop down list to select a rule will be empty.

As promised - Check Tool Check for Adapting RBP roles

For existing customers, deciding to add a new security level to Business Rules comes along with the need to find, review, and potentially adjust permission roles that already exist in the system.

To support that effort, we provide a new Check Tool check, designed to scan all existing roles, and find out the ones that might have been designed for working with business rules before.

Here's an in-depth look at this 2-stepped check:

As I mentioned in the very beginning, the new authorization concept comes with 2 main configuration prerequisites: First, securing the business rule object itself and second, granting the corresponding permissions. This is also reflected in a 2-stepped approach in the Check Tool check.

Step 1 verifies the security setup of the business rules object within the system:

• The check inspects the security section of the business rules object in "Configure Object Definition", to ensure the mandatory settings are correctly maintained.
  • Secured = yes
  • CREATE respects target criteria = yes
• If the business rule object's configuration is incomplete, the assessment stops here, and the result list points out the incomplete configuration.
• The Proposed Solution section of the check offers guidance on how the business rule object configuration needs to be adjusted to meet the required security settings, allowing the process to continue.

Once the initial configuration is verified, the tool proceeds with Step 2 to examine all permission roles associated with business rules maintenance permissions:

• The check evaluates ALL roles, so expect it to run for quite a while 😉, for one of the following criteria:
  • Administrator Permission Metadata Permissions → Configure Business Rules: is flagged AND/OR
  • Administrator Permission → Business Rules Object Permissions: at least one of the actions on the business rule object is flagged
• The Check Tool generates an exhaustive Check Result list of all roles containing any kind of inconsistency in the expected permission configurations regarding business rules.
• Each entry in the result includes:
  • Permission Role Name: Linked directly to the Manage Permission Roles page* for an easy access to review and adapt the role.
  • Identified Issues: Specific details about what inconsistency was detected for this role.
  • Role Status: Current operational status of the role in question (active/inactive).

If you are familiar with the Check Tool, you’ll probably know that some checks are designed to offer a so called “Quick Fix”. We thought about offering such a quick fix in case the check finds roles that violate the expected configuration. However, that would have meant providing all roles with the comprehensive permission to view and edit all business rules again, because we have no way of knowing how a customer has designed the role concept.

We decided against providing such a Quick Fix, as we think the decision to enable the security for the business rule object and benefit from the improved authorization options it offers should be an active decision taken by the customer

If you decide to secure the rules object and implement an enhanced permission concept for your company, you need to review your existing roles and decide which permissions these roles should be granted in the future.

Anything more? - Additional Details to Enhance Your Understanding

1. Execution of Business Rules: What I’d like to point out clearly is that the execution of business rules is NOT AFFECTED, neither by securing the business rule object nor by (mis-) configuring any permission role. Executing rules is independent from the permission to view or maintain rules!
2. Limitation – Field-level Overrides: For a configuration object, such as the Business Rule object, defining field-level overrides doesn’t make sense and is NOT SUPPORTED. If anything is configured for field-level overrides, as in the screenshot below, it’s ignored by the system.

Finally, I hope you agree that the new authorization concept for business rules provides the needed granularity and ensures that users can view or manage rules strictly within their authorized business areas. This enhances both security and operational efficiency.

I also hope you agree with our approach that system administrators must manage permissions proactively to align with the new setup. Proper configuration prevents unauthorized access and this needs to fit the very own customer permission role concept.

The introduction of a new check in the Check Tool is our support to review and adjust permission roles effectively to make the transition as smooth as possible.

And, if there are any open questions, please feel free to comment on this blog. I’d be happy to provide answers. Meanwhile, please check out our What’s New Viewer as well as our enhanced documentation (Permissions for Business Rules, Check Tool check ).

* To effectively utilize the "Manage Permission Roles" UI, users must have RBP Admin View access as a minimum. To actively modify permission roles, RBP Admin Edit permission is required. (Admin Center → “Manage Role-Based Permission Access.”)