Push notifications not triggering for approval workflow task

BPM Mendix
, , , , , , , ,
1

We have an approval workflow in our Mendix 9.18 mobile app where managers need to approve requests. The push notifications stopped working about a week ago - mobile users aren’t receiving any alerts when tasks are assigned to them.

I’ve checked the push notification microflow setup and it looks correct. The device token registration appears to be functioning during app login. However, I’m wondering if there’s an issue with how we’re formatting the payload for cross-platform delivery (we support both iOS and Android).

The workflow itself executes fine - tasks get created and assigned properly in the database. It’s just the notification delivery that’s broken. Has anyone encountered similar issues with push notifications in workflow scenarios?

2

That makes sense! I think we might have been using a generic payload structure. Can someone share an example of how to properly structure the platform-specific payloads in the microflow?

3

I see you’re hitting all three common issues. Let me walk through the complete solution systematically.

1. Push Notification Microflow Setup

Your microflow needs platform detection logic before sending. Add a decision split on the Device.Platform attribute:


IF $Device/Platform = 'iOS' THEN
  SET $Payload := '{"aps":{"alert":"' + $Message + '"}}'
ELSE
  SET $Payload := '{"notification":{"title":"' + $Title + '","body":"' + $Message + '"}}'

2. Device Token Registration

Verify your token refresh logic in the app startup microflow. Tokens should be re-registered on each app launch, not just initial login. Add this check:


CALL RegisterDevice($CurrentUser, $DeviceToken, $Platform)
REFRESH DeviceRegistration WHERE User = $CurrentUser

3. Cross-Platform Payload Formatting

The key issue is iOS requires the ‘aps’ wrapper while Android uses ‘notification’ or ‘data’ objects. Your generic payload won’t work for both. Here’s the proper structure:

For iOS (APNs):

  • Must include ‘aps’ root object
  • Use ‘alert’ for message text
  • Add ‘sound’ and ‘badge’ if needed

For Android (FCM):

  • Use ‘notification’ for display messages
  • Use ‘data’ for background processing
  • Include ‘priority’ field for immediate delivery

Additional Troubleshooting:

  • Verify APNs certificates are valid (they expire annually)
  • Check FCM server key hasn’t been rotated
  • Test with Mendix Push Notifications Connector test function
  • Enable debug logging in the PushNotifications module
  • Verify workflow task assignment triggers the notification microflow

The 200 response you’re seeing means the push service accepted the request, but improper payload formatting causes silent failures on device side. Implementing platform-specific payloads should resolve your issue immediately.

After making these changes, test with both iOS and Android devices to confirm notifications arrive when workflow tasks are assigned.

4

I had a similar issue last month. For iOS, you need to ensure the payload includes the ‘aps’ wrapper with proper structure. For Android, it’s different - you use ‘data’ or ‘notification’ objects. Are you handling the platform-specific formatting in your microflow? Also check if your APNs certificates or FCM server keys are still valid.

5

Good point. I checked and the tokens look valid - they’re being refreshed on each app launch. Here’s what I’m seeing in the logs:


PushNotification.SendNotification: Device token found
Payload: {"title":"Approval Required","body":"New task assigned"}
Result: Success (200)

The API returns success but devices aren’t receiving anything. Could this be a payload formatting issue between platforms?

6

Adding to what raj said - make sure you’re checking the platform type before sending. Your current payload looks generic. You need conditional logic in the microflow to build platform-specific payloads. Also verify that your Firebase Cloud Messaging configuration hasn’t changed recently, especially if you rotated any API keys.