RPA mobile app background processing fails on iOS when triggered from notification

BPM OutSystems
, , , , , , , ,
1

We’re experiencing critical failures with our RPA automation workflows when triggered from iOS mobile notifications. The setup works perfectly on Android, but iOS users report missed automations consistently.

Our process: Users receive push notifications for pending approvals → tap notification → this should trigger background RPA job to sync data and prepare the approval form. On iOS, the background job never completes when the app wasn’t already running. We’re using OutSystems Mobile with the standard notification plugin.

The iOS background execution limits seem to be killing our process, but we need these automations to be user-initiated and responsive. Has anyone solved background RPA processing on iOS with OutSystems Mobile? We’re losing critical approval workflows because of these missed automations.

Current approach:

Notifications.registerCallback(function(notification) {
  RPA.triggerBackgroundSync(notification.data.workflowId);
  Navigation.navigateTo("ApprovalScreen");
});
2

That makes sense. So essentially treat the mobile app as the trigger interface only, not the execution environment. One concern: our approval workflows need to be offline-capable. If we move RPA to server-side, users without connectivity can’t complete approvals. How do others handle offline mobile RPA scenarios?

3

Thanks Maria. The RPA jobs typically run 45-90 seconds, so that explains the timeout. Moving to server-side defeats the purpose though - we need the mobile context (user location, device ID) for the automation. Is there a way to request extended background time in OutSystems Mobile, or should we be using a different plugin approach?

4

Here’s the complete solution addressing iOS background limits, OutSystems Mobile Plugins, and user-initiated triggers:

Architecture Change Required:

  1. Immediate Mobile Context Capture (under 5 seconds):
Notifications.registerCallback(function(notification) {
  var context = {
    userId: $parameters.UserId,
    location: Device.getLocation(),
    timestamp: Date.now()
  };
  ServerActions.InitiateRPAWorkflow(notification.data.workflowId, context);
  Navigation.navigateTo("ApprovalScreen", {jobId: response.JobId});
});

  1. Server-Side RPA Execution: Move your 45-90 second automation to OutSystems server-side process automation. The mobile app just initiates and monitors.

  2. Real-time Status Updates: Use OutSystems Mobile’s WebSocket plugin or polling mechanism:

setInterval(function() {
  ServerActions.CheckJobStatus($parameters.JobId).then(function(status) {
    if (status.IsComplete) { /* update UI */ }
  });
}, 2000);

iOS Background Handling: For the notification tap itself, use beginBackgroundTaskWithExpirationHandler through a custom OutSystems plugin if you need guaranteed completion of the initiation call. But keep this under 10 seconds.

Offline Support: Implement queue-based approach - store approval decisions locally with OutSystems Local Storage plugin, sync when online. The RPA workflow executes server-side after sync, not during the mobile interaction.

Testing: iOS Simulator doesn’t accurately reflect background time limits. Test on physical devices with the app fully terminated, not just backgrounded.

This architecture respects iOS constraints while maintaining user-initiated trigger semantics. The automation still responds to user action, it just executes server-side where it belongs for reliability and cross-platform consistency.

5

You’re mixing concerns here. RPA workflows shouldn’t depend on mobile device context for 45-90 second operations. Split your process: capture the mobile context immediately (location, device ID) and pass it to a server-side RPA job as parameters. The mobile app just initiates and monitors. Use OutSystems’ background task API to start the server job, then poll for completion or use websockets for real-time updates. The mobile plugin limitation isn’t your real problem - it’s the architectural assumption that RPA must run client-side. iOS will never give you 90 seconds of background processing reliably, regardless of which plugin you use.

6

Offline RPA is contradictory - RPA by definition automates interactions with other systems, which requires connectivity. For offline approvals, you’re looking at local data sync, not RPA. Cache the approval data when online, allow offline decision capture, then sync when connectivity returns. The RPA workflow (data validation, system updates, notifications to other users) happens server-side after sync. Don’t try to force RPA into offline mobile scenarios.