Process mining RPA bot fails to trigger approval workflow for procurement requests

BPM OutSystems
, , , , , , , ,
1

We’ve deployed an RPA bot in our process-mining module to automatically extract procurement request data and trigger approval workflows. The bot successfully reads purchase requisitions and updates the status field, but the approval workflow never initiates.

The event mapping in the workflow engine appears correct - we’ve configured it to listen for status changes from ‘Submitted’ to ‘Ready for Approval’. However, when the RPA bot updates this field, nothing happens. Manual updates through the UI work fine.

Here’s our current bot configuration:


BotAction: UpdateEntity
Entity: ProcurementRequest
Field: StatusId = 3 // Ready for Approval
TriggerWorkflow: true

The integration connector configuration shows active status, and we’re not seeing any errors in the bot execution logs. We’re experiencing significant procurement delays because requests are stuck waiting for manual intervention. Has anyone encountered similar issues with RPA-triggered workflow events?

2

Let me provide a comprehensive solution that addresses all three critical areas: event mapping, status field updates, and integration connector configuration.

Event Mapping in Workflow Engine: First, verify your workflow is configured to accept programmatic triggers. In Service Studio, open your approval workflow and check the ‘Start’ node properties. Enable ‘Allow External Triggers’ and note the workflow identifier (you’ll need this for the API call).

Status Field Update by RPA Bot: The core issue is that your bot’s UpdateEntity action bypasses the application logic layer. You need to create a server action that properly updates the status AND triggers the workflow:


// Server Action: UpdateProcurementStatus
ProcReq = GetProcurementRequestById(RequestId)
ProcReq.StatusId = NewStatusId
UpdateProcurementRequest(ProcReq)
TriggerWorkflowEvent(
  WorkflowId: "ProcurementApproval",
  EntityId: RequestId
)

Then expose this as a REST API endpoint that your bot calls.

Integration Connector Configuration: Modify your RPA bot to use REST API calls instead of direct entity updates:

  1. In the integration connector, change BotAction from ‘UpdateEntity’ to ‘CallRESTAPI’
  2. Configure endpoint: POST /api/procurement/updatestatus
  3. Pass RequestId and NewStatusId as parameters
  4. Add authentication headers (use service account token)

This approach ensures that:

  • Workflow events fire correctly because you’re using the proper server action
  • Status updates are atomic and include all necessary triggers
  • The integration connector maintains proper audit trails
  • Performance remains good (typically 150-200ms per request)

After implementing this, test with a single procurement request first. Monitor the workflow execution logs in Service Center to confirm the approval workflow initiates. If you’re still experiencing issues, check that your service account has permissions to trigger workflows - this is a common gotcha that’s easy to overlook.

One final note: if you have high volume (>1000 requests/day), consider implementing a queue-based approach where the bot writes to a staging table and a separate timer processes the queue with proper workflow triggers. This prevents timeout issues during peak loads.

3

I want to add that you should also verify your process-mining module version compatibility with the RPA framework. We had a similar situation where certain bot actions weren’t compatible with workflow triggers due to version mismatches between modules. After upgrading both to OutSystems 11.14, the integration worked seamlessly. Check your Service Center for any compatibility warnings.

4

Exactly right. Here’s what worked for our team - we created a lightweight API wrapper that the bot calls instead of direct entity manipulation. The wrapper ensures proper workflow event firing while maintaining good performance.

5

The problem is definitely the UpdateEntity bot action - it’s designed for speed and bypasses the application logic layer. You need to create a custom server action that wraps the entity update and explicitly triggers the workflow. I had the same issue last month with a different module. The fix involves modifying your integration connector to call a REST API endpoint that executes the proper server action instead of using the direct UpdateEntity approach.