What it does

Push notifications send messages to a customer's mobile app from inside a journey, alongside email and text. Customer Insights - Journeys handles the message, the audience and the orchestration; the client's own iOS and Android app has to be built to register devices and receive them.

Key facts

• Configuration starts at Settings > Customer engagement > Push notifications > +New mobile app, where you register a mobile app configuration with a name and description.
• iOS connects to APNs one of two ways. Certificate mode takes a .p12 upload. Token mode takes the Signing key (the content of the .p8 between the BEGIN and END private key lines, with line breaks stripped), a 10-character Key ID, the Bundle ID and the Team ID.
• Android connects through FCM and needs the FCM key from the app developer. There's a separate documented transition for moving legacy Android push registrations onto FCM tokens — check whether the client's app is already on the new scheme.
• Credentials are held in secured fields. If anyone other than a system administrator is going to create mobile app configurations, they need adding to the Marketers - Mobile app secrets and Marketers - Mobile app channel instances secrets field security profiles under Advanced settings.
• Once saved, the Developer information tab exposes the values the app developer needs to wire the app to your environment.
• The developer's side of the work is four pieces of documented effort: user mapping, device registration, receiving notifications on the device, and interaction reporting. Without device registration you have no addressable audience, and without interaction reporting you have no analytics.
• Messages are created under Channels > Push notifications > +New push notification, with Title, Subtitle, Message and Image fields, and separate iOS and Android previews.
• On-click behaviour is either Open the app or Open the browser at a URL. Images should be roughly 2:1 and are subject to the platform limits iOS and Android impose.
• Personalisation works the same way as text: the Personalization button in the Message field, with Audience, Trigger and Compliance as data sources, and inline {{#if}} / {{else if}} / {{else}} / {{/if}} conditions.
• A compliance profile and purpose are required, but no consent checks are performed on push. Quiet times configured on the compliance profile are still enforced.

When to use / skip

Push only makes sense if the client already has a mobile app with a meaningful installed base and a development team who can take on the SDK work. That's the gate, and it disqualifies most projects. When the app exists, push is the cheapest per-message channel available and the one with the best immediacy, so it's worth doing properly.

Skip it if the app is a roadmap item, if the app team is a third party with a release cadence measured in quarters, or if the client is imagining browser-based web push — that isn't what this is.

The other thing to weigh is that push here is a marketing channel, not a product notification system. If the app already sends operational notifications through its own backend, adding a second sender introduces a coordination problem that nobody owns.

Configuration decisions

• Certificate versus token authentication for APNs. Token is less painful — certificates expire and the renewal always lands during a freeze.
• One mobile app configuration or several, if the client ships separate apps per brand, per market, or a customer app and a staff app.
• How the app's users map to contacts or leads in Dataverse, which is the single decision that determines whether the channel can be targeted at all.
• Which compliance profile and purpose push messages use, given that consent isn't enforced on this channel and quiet times are the only guard rail the profile gives you.
• Whether tapping a notification opens the app or a browser URL, and if the app, what deep link handling the app team needs to build.
• Who owns the split between marketing push and product push, and how frequency across both is controlled.

Gotchas

• No consent checks are performed on push. Compliance profiles and purposes are recorded, but nothing blocks a send the way it would on email — you own the opt-out logic in the app and in your segmentation.
• The .p8 signing key has to be pasted with line breaks removed. Paste it as-is and it fails validation with an unhelpful message.
• APNs certificates expire. A push channel that has worked for a year stops on a specific date, and nobody has a reminder in a calendar.
• Non-admin users can create the mobile app record but silently fail on the secret fields until the field security profiles are set. It looks like the save worked.
• Device registration is app-side. If the app team skips it, the channel appears fully configured on the Dynamics side and simply has no audience.
• Interaction reporting is also app-side and separate from device registration. Skip it and the journey analytics for push stay empty while everything else looks fine.
• Legacy Android push tokens need migrating to FCM tokens. An older app build can look healthy right up to the point delivery stops.

Consultant notes

• Book the app development team into the project plan before you commit to a push go-live date. The Dynamics configuration is an afternoon; the app work is not.
• Demo the iOS and Android previews side by side — title truncation differs between platforms and it's the fastest way to get the client writing shorter titles.
• Be explicit in writing that consent is not enforced on this channel, and agree how opt-out is handled. This is the item most likely to come back at a compliance review.
• Put the APNs certificate expiry date in a shared calendar, or use token authentication and avoid the problem.
• Check before go-live that a test device registers, receives, and reports an interaction back into the timeline. All three, not just the first two.

---

Worth another look after the Android FCM token transition deadline, or if consent enforcement is ever added to the push channel.