In the world of app development and workflow automation, there are scenarios where we need to initiate a workflow and ensure that we know precisely who triggered it. This information could be crucial for notifying the person once the workflow is completed, handling request approvals, or assigning tasks to specific individuals.

In this blog post I will explain how you can easily propagate user credentials from Build Apps to Build Process Automation workflow triggered by API call in scenarios where you SAP Build Apps and SAP Build Process Automation are deployed on the same tenant.

I’m assuming you are familiar with a way to tigger Build Process Automation workflow from Build Apps. If not, please refer to this tutorial (Create a Sales Order App Using SAP Build Apps).

In our scenario, we have a mobile app created in SAP Build Apps, featuring utility incidents displayed on a map and a dashboard that shows these incidents as cards. Field workers can initiate a Work Order request workflow by clicking on a specific incident card action.

While the workflow’s details are beyond the scope of this blog post, in summary, we make use of the GenAI service to estimate resolution times based on past incidents and location data. Additionally, we generate recommendations for a human operator to verify and approve the Work Order request. Finally, a bot creates the Work Order in the S4 backend system and returns the Work Order number to the mobile app.

When we trigger the workflow using the button in our app, it uses a standard destination with OAuth2ClientCredentials. However, this results in the workflow being initiated by a generic user, as shown in the images (1-3) below:

Picture 1: default destination

Picture 2: Incident card in SAP Build Apps mobile cockpit

Picture 3: Process and Workflow Instances – Monitoring cockpit

Regardless of who is authenticated in the app, the user who initiates the workflow instance remains the same (a generic user). This is not suitable for our scenario.

Solution

To address this issue, follow these steps:

• In the BTP cockpit, duplicate the existing destination and give it a different name, such as “SBPA_Apps_with_credentials”. Change the authentication to OAuth2UserTokenExchange.

Picture 4: new destination

• In your SAP Build Apps project, navigate to the Data section, open an existing data entity, and configure the SAP BTP destination for REST API integration(picture 5 below).

Picture 5: SAP BTP destination REST API integration setup

And that’s it!

Result

By modifying the destination in the BTP Cockpit and adjusting the target destination in your SAP Build Apps project, you can now initiate the workflow process from your app. You will notice that the “started by” metadata value in the workflow is now correctly attributed to the user who authenticated in SAP Build Apps.

Picture 6: Person that started the SBPA workflow is the same as one authenticated in SAP Build Apps

Depending on your specific process requirements, you can also take advantage of principal propagation in SAP Build Process Automation to pass credentials when creating or modifying items in systems like S4. This allows you to avoid using a technical user for authentication.

For more details on achieving this, please refer to the following blog posts:

• How to setup Principal Propagation for Actions project in SAP Build Process Automation
• Principal Propagation (Run a Step on Behalf of) in SAP Build Process Automation

By following these steps, you can ensure that user credentials are correctly propagated within your SAP environment, enhancing the traceability and security of your workflow processes.

Enjoy Building. 😀