Connecting mobile service events to customer journeys in Adobe Journey Optimizer

Hi ​@good_hand0f17 ,
I'd keep the connectivity platform as the system of record for live service state and use AJO for customer communications. Send customer-actionable state changes, not every telemetry sample.

Good candidates to send: activation confirmed, first successful connection (if it starts onboarding), low-balance threshold crossed, renewal due/renewed, and service interruption started/restored. Keep frequent balance polls, heartbeats, and network diagnostics operational unless there is a specific activation or analytics use case. For a per-subscriber event, use a streamed XDM ExperienceEvent; the current AJO event setup guidance requires a Profile-enabled event schema with a person-based primary identity. A network-wide event affecting a subscriber group is a different Business Event + Read Audience pattern, not the same as a per-person trigger.
https://experienceleague.adobe.com/en/docs/journey-optimizer/using/configure-journeys/events-journeys/about-events
https://experienceleague.adobe.com/en/docs/journey-optimizer/using/configure-journeys/events-journeys/experience-event-schema

Identity: Resolve each event in the connectivity system to the intended customer/subscriber's stable person ID, such as a CRM/customer ID in the agreed AEP namespace. Keep subscriptionId and device/SIM identifiers as event context—not as the person ID if they can be shared or reassigned. If one customer can have multiple plans and each needs its own journey path, use subscriptionId as AJO's supplemental identifier. AJO documents separate journey instances per profile-plus-supplemental-ID; the supplemental ID must be a string, and a profile is limited to 10 concurrent journey instances. Check journey arbitration/capping as well.
https://experienceleague.adobe.com/en/docs/experience-platform/xdm/ui/fields/identity
https://experienceleague.adobe.com/en/docs/journey-optimizer/using/orchestrate-journeys/manage-journey/supplemental-identifier

Journey or API-triggered campaign? Use a Journey for multi-step lifecycle logic—for example, low balance -> wait/check current status ->send a reminder only if the balance is still low. Use an API-triggered Transactional campaign when the service system has validated a specific event and needs to initiate one 1:1 message with event context in the API request. AJO documents event-triggered journeys as potentially taking up to five minutes to process their first action; for a hard operational SLA, keep the critical alert path in the service platform unless the end-to-end AJO path has been tested against that SLA.
https://experienceleague.adobe.com/en/docs/journey-optimizer/using/get-started/essentials/journeys-vs-campaigns
https://experienceleague.adobe.com/en/docs/journey-optimizer/using/campaigns/api-triggered-campaigns/api-triggered-campaigns

Duplicates and stale alerts: Deduplicate upstream with a stable sourceEventId/idempotency key, reused on retries; publish threshold crossings or meaningful state transitions rather than every balance update. Include event time, state version, and an expiry/valid-until value. Before sending, check the authoritative service state and suppress the alert if the balance recovered, renewal completed, or service was restored. AJO's default five-minute re-entry behavior is a journey-entry guardrail—not a substitute for per-subscription idempotency or a current-state check. Test retries, two subscriptions for one profile, out-of-order events, and recovery before send.
https://experienceleague.adobe.com/en/docs/journey-optimizer/using/orchestrate-journeys/manage-journey/entry-management
https://experienceleague.adobe.com/en/docs/journey-optimizer/using/orchestrate-journeys/manage-journey/supplemental-identifier
https://experienceleague.adobe.com/en/docs/journey-optimizer/using/configure-journeys/events-journeys/about-events