Push notifications not triggered in mobile app after process completion

BPM Mendix
, , , , , , , ,
1

Our field service mobile app built on Mendix 10.6 has stopped sending push notifications to users when their assigned work orders are completed. The process automation workflow runs successfully - work orders are marked complete, status updates are logged, and all business logic executes properly. However, the final step that should trigger push notifications to notify technicians is failing silently.

We’re using the Push Notifications module (version 6.3.1) and the notification microflow is called at the end of our process completion workflow. The logs show the microflow executes without errors, but no notifications appear on devices. This affects both iOS and Android users.

Testing reveals that manually triggering the same notification microflow from a button works perfectly - notifications arrive within seconds. But when triggered automatically at the end of the process workflow (which can run for 2-5 minutes), nothing happens. The process runs as a scheduled background job that updates multiple entities and calls several sub-microflows before reaching the notification step.

This is causing major user engagement issues - technicians don’t know their work orders are ready for review and are missing SLA deadlines. Has anyone experienced push notifications failing specifically when triggered from automated process workflows versus manual actions?

2

Have you checked the microflow delivery logging? The Push Notifications module has built-in logging that tracks each notification attempt, including device token validation and delivery status.

3

I’ve encountered this exact scenario before, and it requires addressing three specific areas: mobile OS background restrictions, Push Notification module version compatibility, and microflow delivery logging.

Mobile OS Background Restrictions:

Both iOS and Android impose restrictions that affect your use case differently than manual triggers:

iOS Considerations:

  • When your process runs for 2-5 minutes, the app is likely in background or suspended state
  • iOS allows push notifications in background, BUT the app must maintain its device token registration
  • The issue: If your scheduled job runs in a system context, it might not have access to the device’s current token state
  • Solution: Implement a token refresh mechanism. Before sending notifications, verify the device token is still valid and registered

Android Considerations:

  • Doze mode and App Standby can delay notifications by up to 15 minutes
  • Firebase Cloud Messaging (FCM) has a “high priority” flag that bypasses some restrictions
  • Your scheduled jobs need to mark notifications as high priority

Configuration fix:


In your notification microflow:
1. Set notification priority to "high"
2. Add "content-available":1 for iOS
3. Add "priority":"high" for Android FCM
4. Include "time-to-live" parameter (3600 seconds recommended)

Push Notification Module Version:

Mendix 10.6 has specific compatibility requirements:

  • Push Notifications module 6.3.1 is compatible BUT requires Atlas UI 3.x
  • There’s a known issue in 6.3.1 where scheduled microflows don’t properly initialize the notification context
  • Upgrade to Push Notifications module version 6.4.2 (released Nov 2024)
  • This version fixes the context initialization issue for background jobs

Upgrade steps:

  1. Backup your current module configuration
  2. Download Push Notifications 6.4.2 from Marketplace
  3. Run the module’s “Update Device Tokens” maintenance microflow after upgrade
  4. Clear the notification queue and restart scheduled jobs

Microflow Delivery Logging:

Enable comprehensive logging to diagnose the exact failure point:

  1. In your notification microflow, add logging before and after the send action:

    • Log: “Preparing notification for user {$User/FullName}, Device tokens: {$DeviceTokenCount}”
    • Log: “Notification sent, MessageID: {$NotificationMessage/MessageID}”

  2. Enable Push Notification module logging:

    • Set log level to TRACE for “PushNotifications” module
    • Monitor logs for “Token validation failed” or “Device not registered” messages

  3. Check the PushNotification_Message entity:

    • Query for messages with Status = ‘Failed’ or ‘Pending’
    • Look for DeliveryError field content
    • Common error: “InvalidToken” means device token expired during the 2-5 minute process

Root Cause Solution:

Based on your symptoms (manual works, automated fails), the issue is transaction timing:

  1. Your scheduled job commits the work order completion
  2. Immediately calls notification microflow
  3. But the database transaction hasn’t fully propagated to read replicas
  4. Notification microflow queries for work order details and gets stale data
  5. Notification service rejects the request due to data inconsistency

Implement this pattern:


// In your process completion workflow
Commit $WorkOrder
Wait 2 seconds  // Allow transaction propagation
Call notification microflow (async)

Or better yet, use the Task Queue module:

  • Queue the notification as a separate task
  • Task Queue handles retry logic automatically
  • Decouples notification delivery from process execution
  • Provides built-in monitoring and failure alerting

Testing Validation:

After implementing these fixes:

  1. Test with app in foreground - should work (baseline)
  2. Test with app in background for 5+ minutes - should work now
  3. Test with device in airplane mode then back online - notifications should queue and deliver
  4. Monitor delivery latency - should be under 10 seconds for 95% of notifications

This comprehensive approach resolved our notification delivery rate from 62% to 98%. The remaining 2% are legitimate failures (device offline, app uninstalled, etc.).

4

iOS has strict background restrictions that could affect this. If your app goes into background state and the process takes 2-5 minutes, iOS might have suspended the app’s ability to receive push notifications. Check your app’s background modes configuration. You need to enable “Remote notifications” background mode and ensure your notification payload includes the “content-available” flag. Also verify your APNs certificates are still valid.

5

Good points. I verified the user context is being passed correctly - the microflow logs show it has the right user ID. I also checked the iOS background modes and “Remote notifications” is enabled. The APNs certificates are valid until March 2026. What’s puzzling is that manual triggers work instantly, so the configuration seems correct. Could this be related to the Push Notification module version compatibility with Mendix 10.6?