Overview
Well-designed workflows can automate business processes and ensure data quality.
With SAP SuccessFactors Employee Central, you have the full capability of automated approval processes that control the changes to important employee and corporate data.
The conditions under which a Workflow gets triggered can be defined in two different ways:
Please note that it is highly recommended for new customers to use Business Rules for triggering workflows instead of the XML, as any changes can be made in Admin Center without the need to access Provisioning.
Nevertheless, there are still companies relying on the XML for Workflows and interested in transitioning to a more user-friendly method to manage their own workflows without having to rely on Partners who can access Provisioning.
In this blog post, I will explain the steps needed to ensure a smooth transition from XML-based workflows to Workflow Derivation Business Rules and a few considerations to be taken into account throughout the transition.
There is a lot of content out there on this topic, but having everything in a 3 minutes read article, fully validated, and implemented multiple times can be really handy.
Step 1: Export a backup of the XML
This step is performed in Provisioning -> Import/Export Rules XML for Workflow Derivation.
Note: this is very important firstly because it works as a backup to be imported in case anything goes wrong, and, secondly, it contains the already existing workflows to be migrated to the instance through business rules.
Step 2: Analysis of workflows currently implemented
It is now necessary to analyse the workflows and conditions currently listed in the XML and make sure that they are correctly migrated in the business rules.
It is convenient to divide the workflows triggered according to the specific scenario and most importantly, the portlet in which they will be triggered.
This will be very useful in step 5 when the business rules will be attached in the BCUI and each portlet will have its own set of conditions and workflows.
Step 3: Switch in Provisioning
Still in Provisioning, under Company Settings, check the option "Enable Business Rules for Workflow Derivation".
Note: as soon as this option is checked, the checkbox "Import/Export Rules XML for Workflow Derivation" mentioned above will disappear, therefore make sure you took a backup of the XML first (Step 1).
Step 4: Build the Business Rules
In this step, you will create the business rules that will trigger the workflows.
Please note that it will be key to replicate the AND/OR conditions properly.
As mentioned above, there should be one business rule per portlet and it should contain the If - Else If - Else conditions, according to the XML backup file exported in step 1.
Note: we are introducing the conditions, but the workflows should already exist as they were also mentioned in the XML.
In case new workflows need to be introduced, this can be done in "Manage Organisation, Pay and Job Structures".
The new workflows will then be selectable in the business rule.
Step 5: Attach the Business Rule in the BCUI
Once all the business rules have been created, they need to be attached in "Manage Business Configuration" under each portlet.
Note: as per H1 2021, a new error message shows in case the business rule is NOT attached as an onSave rule.
Step 6: Test the Business Rules
As with any implementation, it is highly recommended to perform the steps in a Development/Test environment first and then move it to Production after being fully tested and validated.
In this last step, in case the implementation has been performed in Dev or Test, the business rules can be tested in order to make sure that the workflows are triggered properly.
You will select a user and test all the different scenarios, expecting the right workflow to be triggered.
You can use a Rule Trace in order to check which workflow is triggered, or alternatively, you can temporarily amend the workflow tested by adding your name in order to identify that specific workflow.
This is a validation step that, if performed now, doesn't need to be replicated in Production and will ensure that the migration to business rules is successful.
More information
Please refer to the following Knowledge Base Articles to learn more or troubleshoot issues related to this topic:
Note: In the last releases, SAP has been trying to migrate from XML to UI-based processes, giving customers the possibility to make changes directly in Admin Center without the need to access Provisioning and involve implementation partners.
A similar approach applies to Event Reason Derivation XML being deprecated in H2 2020), and from now on, business rules must be used for deriving an event reason.
Well-designed workflows can automate business processes and ensure data quality.
With SAP SuccessFactors Employee Central, you have the full capability of automated approval processes that control the changes to important employee and corporate data.
The conditions under which a Workflow gets triggered can be defined in two different ways:
- Rules XML for Workflow Derivation
- Business Rules for Workflow Derivation
Please note that it is highly recommended for new customers to use Business Rules for triggering workflows instead of the XML, as any changes can be made in Admin Center without the need to access Provisioning.
Nevertheless, there are still companies relying on the XML for Workflows and interested in transitioning to a more user-friendly method to manage their own workflows without having to rely on Partners who can access Provisioning.
In this blog post, I will explain the steps needed to ensure a smooth transition from XML-based workflows to Workflow Derivation Business Rules and a few considerations to be taken into account throughout the transition.
There is a lot of content out there on this topic, but having everything in a 3 minutes read article, fully validated, and implemented multiple times can be really handy.
Step 1: Export a backup of the XML
This step is performed in Provisioning -> Import/Export Rules XML for Workflow Derivation.
Note: this is very important firstly because it works as a backup to be imported in case anything goes wrong, and, secondly, it contains the already existing workflows to be migrated to the instance through business rules.
Step 2: Analysis of workflows currently implemented
It is now necessary to analyse the workflows and conditions currently listed in the XML and make sure that they are correctly migrated in the business rules.
It is convenient to divide the workflows triggered according to the specific scenario and most importantly, the portlet in which they will be triggered.
This will be very useful in step 5 when the business rules will be attached in the BCUI and each portlet will have its own set of conditions and workflows.
Step 3: Switch in Provisioning
Still in Provisioning, under Company Settings, check the option "Enable Business Rules for Workflow Derivation".
Note: as soon as this option is checked, the checkbox "Import/Export Rules XML for Workflow Derivation" mentioned above will disappear, therefore make sure you took a backup of the XML first (Step 1).
Step 4: Build the Business Rules
In this step, you will create the business rules that will trigger the workflows.
Please note that it will be key to replicate the AND/OR conditions properly.
As mentioned above, there should be one business rule per portlet and it should contain the If - Else If - Else conditions, according to the XML backup file exported in step 1.
Note: we are introducing the conditions, but the workflows should already exist as they were also mentioned in the XML.
In case new workflows need to be introduced, this can be done in "Manage Organisation, Pay and Job Structures".
The new workflows will then be selectable in the business rule.
Step 5: Attach the Business Rule in the BCUI
Once all the business rules have been created, they need to be attached in "Manage Business Configuration" under each portlet.
Note: as per H1 2021, a new error message shows in case the business rule is NOT attached as an onSave rule.
Step 6: Test the Business Rules
As with any implementation, it is highly recommended to perform the steps in a Development/Test environment first and then move it to Production after being fully tested and validated.
In this last step, in case the implementation has been performed in Dev or Test, the business rules can be tested in order to make sure that the workflows are triggered properly.
You will select a user and test all the different scenarios, expecting the right workflow to be triggered.
You can use a Rule Trace in order to check which workflow is triggered, or alternatively, you can temporarily amend the workflow tested by adding your name in order to identify that specific workflow.
This is a validation step that, if performed now, doesn't need to be replicated in Production and will ensure that the migration to business rules is successful.
More information
Please refer to the following Knowledge Base Articles to learn more or troubleshoot issues related to this topic:
- 2260431 - How To Enable Business Rules for Workflow Derivation and Event Derivation
- 2542271 - Business rules for Workflow Derivation Priority
- 2227342 - Workflows no longer trigger
- 2569624 - Triggering Workflows via Business Rules - Cannot Find WfConfig in Rule Menu
- 2571698 - Best practices setting up business rules for event reason derivation
Note: In the last releases, SAP has been trying to migrate from XML to UI-based processes, giving customers the possibility to make changes directly in Admin Center without the need to access Provisioning and involve implementation partners.
A similar approach applies to Event Reason Derivation XML being deprecated in H2 2020), and from now on, business rules must be used for deriving an event reason.
- SAP Managed Tags:
1 Comment
