Product Information
Configuring Subprocesses in SAP Build Process Automation
Modularising your Process Automations
As I have highlighted in my recent blog Introducing Subprocesses as Referenced Subflows in SAP Build Process Automation, you can easily modularize your process automation projects, create and reuse a set of common process activities in a subflow, and leverage them in one or across multiple master processes without duplicating efforts.
Today, I will describe how you can easily configure subprocesses as embedded and referenced subflows and dramatically simplify process models, thus increasing the understandability and clarity of your flows.
Configuration Ingredients of a Subprocess
In order to leverage subprocesses, you should consider:
- Subprocess Input to pass variables to the activities of the subprocess from the main process
- Subprocess Output to pass variables from the subprocess to the main process
- Configuration settings to build embedded or referenced subprocess with an API Trigger
- Requires a 2-step approval for all hardware (Manager and IT Services) in Organisation 0002
- Allows an accelerated approval logic for any requests in Organisation 0001 <2.000€ and the Cost Center Owner approval is all that is needed
- Demands an advanced approval logic for all hardware requirements >=2.000€ with a multi-step approval logic.
- Requires as a standard in Organisation 0001, a Cost Center Budget Officer reviews all requests before a business rule automatically shall evaluate and provide the decision logic for the above business requirements.
Stage 1: The Main Process with 2 Subprocesses
Fig4: The above data type definition is leveraged for the business rules as well as the Subprocess Input und Output definition.
Stage 2: Creating an additional Subprocess
Let me now further modularise the pretty complex main process, as (a) the main process still features directly approval process logic for Organisation 0002 and hence some steps that are duplicates, e.g. the action to create a Purchase Requisition in SAP S/4HANA and the business validation form and email-notifications.
Fig8: I create a new subprocess for 0002 2-step approvals and delete all unnecessary process steps that can be omitted.
Subprocesses at Runtime
Fig14: I created multiple line-items to order a couple of MacBooks and selected Organisation 0001. The Cost Center Budget Officer is asked to review the request to check if this is in budget.
Conclusion
Subprocesses as referenced subflows are a powerful addition to our process automation platform, providing users with the ability to create and reuse a common set of process automation steps (workflows, forms and approval tasks, bot automations, business rules) across multiple processes. With Subprocesses, you can streamline your process automations, reduce the risk of errors, and simplify maintenance. In upcoming blogs, we will explain how to configure process visibility for subprocesses and how we plan to enable for-each and par-for-each loops, send back and exceptions.
For an update on regular release updates, please have a look at What’s New for SAP Build Process Automation.
We hope you enjoy using this new feature and look forward to your feedback.
Disclaimer:
Please note that the example that I use above is a simple demonstration example, covering a departmental pre-approval of requisitions before Orders are created in SAP S/4HANA. It is not intended to re-build any as-is business application functionality.
Hi Thomas Volmering Thanks for the blog. One of my customers has multi-level approval scenarios, where we need a loop. I understand that the iterative flow logic is available in Q2 2023. But, I think, we can use a sub-process approach for achieving multi-level approval scenarios (not just 2 level of approvals as mentioned in this blog) without the need for iterative flow logic. Can you please confirm?
Thanks, manju
Hi Manjunath,
yes, multi-level approval logic can be implemented with or without embedded or referenced subflows. You can simply add conditions, additional steps and adjust the receiver determination rule (decision table). Using subprocesses helps to modularise comprehensive process automations and simplify the overall main process model. Iterative flow logic is more about loops (for-each and par-for-each) and send back to requester. We are working on that. In doubt, you can as well build a complex workflow with the Workflow Editor in SBAS, deploy it to SBPA and include it as a subprocess in the SBPA process as described in this blog.
Regards,
Thomas
Hi Thomas.
Thanks for this sharing this example.
We are currentyl evaluation the worflow solution as we consider it could bring a lot of value w/o reinventing our information system.
However I am strugling on one blocking point to build our futures workflows in a context of EDA.
We want to build some workflows that would allow interaction with users but as well some with "events" that take place on the backend.
However, the only place we can catch a trigger seems to be the beginning of the process.
Thus I tought I could use sub process with another event to trigger the next steps. Unfortunately, using a sub process disable this second event. Thus I can not condition the sub process to the two events, main process reached the sub process AND one event is raised.
Is there any way to master such a combined starting condition or simply to get a sort of "Event" listener that I could use instead for non human actions ?
on the top of this, a standard connector from advanced envent mesh to SAP Build Process Automation would be nice 🙂
Thanks.