Mobile approval workflow push notifications not triggering on iOS devices

BPM OutSystems
, , , , , , , ,
1

We have an approval workflow built in OutSystems Service Studio where managers need to approve expense reports via mobile app. The push notifications were working fine until last week, but now iOS users aren’t getting notifications when new approval tasks are assigned to them. Android devices still receive them without issues.

I’ve checked the workflow logic triggers and they’re firing correctly in the server logs. The push notification registration appears successful on app launch, but the actual notifications never reach iOS devices. Device tokens seem to be stored in our database, but I’m wondering if there’s an issue with how we’re managing token refresh or the notification payload format.

This is causing serious delays in our approval process since managers don’t know they have pending tasks until they manually open the app.

2

After digging deeper with everyone’s suggestions, I found the root cause. The issue was a combination of problems related to all three focus areas:

Push Notification Registration Issue: Our device token registration was happening correctly on initial app launch, but we weren’t properly handling the scenario where iOS refreshes tokens in the background. I added proper handling for the token refresh callback:

function onTokenRefresh(newToken) {
  RegisterDevice(newToken, GetUserId(), "iOS");
  UpdateLocalTokenCache(newToken);
}

Workflow Logic Triggers: The workflow was firing correctly, but the SendPushNotification action was using a cached user list that didn’t account for users who had reinstalled the app. I modified the workflow to query active device registrations in real-time:

SELECT DeviceToken, Platform
FROM DeviceRegistration
WHERE UserId = @UserId AND IsActive = 1

Device Token Management: The critical issue was that we weren’t invalidating old tokens when new ones were registered. This caused the notification service to attempt delivery to stale tokens first, and our retry logic wasn’t configured properly. I implemented:

  1. Token invalidation on new registration - set IsActive=0 for old tokens before inserting new ones
  2. Added a cleanup job to remove tokens older than 90 days
  3. Implemented proper error handling to catch APNs feedback about invalid tokens
  4. Updated the notification payload to include the correct content-available:1 flag for background delivery

The payload structure now looks like:

{
  "aps": {
    "alert": {
      "title": "New Approval Request",
      "body": "You have a pending expense approval"
    },
    "badge": 1,
    "sound": "default",
    "content-available": 1
  },
  "taskId": "12345",
  "priority": "high"
}

After deploying these changes, iOS push notifications are working reliably again. The key was ensuring the entire token lifecycle was managed properly - from registration through refresh to invalidation. Also critical was querying live device registrations in the workflow rather than relying on cached data.

Thanks everyone for the guidance - the suggestions about token refresh and payload structure pointed me in the right direction!

3

Good point about the payload structure Lisa. I compared our Android and iOS notification payloads and found some differences. Going to review the aps dictionary format more carefully.

4

Have you verified that your Apple Push Notification service (APNs) certificates are still valid? They typically expire annually and this is a common cause of iOS-specific notification failures. Also check if the certificate is for production or development environment - mismatches there can cause silent failures.

Another thing to check: are the device tokens being updated properly when users reinstall or update the app? iOS device tokens can change, and if you’re not handling the token refresh events correctly, you might be sending to stale tokens.