Customer Insights – Journeys: Asset Library + Exit Conditions + Child-table Triggers

Source: Claude.ai chat (original: trigger-based-journey-contact-field-requirements__2c34bfa6.md) Added: 2026-10-02

Summary

• The Asset Library has no folder structure — three organizing mechanisms, none hierarchical: Tags (manual + AI auto-tagging) · Type tabs (images / videos / documents) · Search + filter. Tags are the only scheme exposed in the email editor's picker.
• Journey exit gives three independent levers (OR'd, not composable): Exit when an event occurs (immediate trigger exit) · Exit by segment (immediate on segment match, latency = refresh cadence) · End date (no new entries; in-flight finish).
• Child-table triggers: a journey can start from a child record (via contact lookup) but once it starts, the entity travelling through is the Contact. Segments only exist for Contact / Lead / CI-Data profiles — so the exit segment must be contact-based. Exit trigger can be on any table that resolves to a contact.

Key takeaways

• Design a faceted tag taxonomy rather than freeform tags: Purpose (logo/hero/icon/photo/doc/ics) · Campaign-or-program · Language. Pair with a filename convention (e.g. ORG_EN_Campaign_Hero_2026.png) so name search and tag filter both work. Prune AI auto-tagging noise (sky, smiling, outdoor) on upload — otherwise the deliberate taxonomy gets buried.
• Library assets are solution-aware — can move dev → INT → PROD via solution without re-uploading and breaking URLs.
• Business-unit scoping on the unified library is the one genuine partitioning you get — keeps one team's library out of another's picker.
• Exit-by-segment ≠ Exclude-this-segment. Exclusion = entry criteria (stops people entering). Exit = yank out mid-flight. For CASL-style suppression on consent withdrawal, you generally need both — exclusion so they never enter + exit so anyone who withdraws mid-journey stops getting the rest.
• Latency: trigger exits are genuinely immediate. Segment membership evaluates on refresh cadence → someone can still receive the next message in the window before segment updates. If consent withdrawal must stop sends immediately, drive it off a trigger on the consent field change, not off a segment.
• Journey goals also use triggers but are measurement only — they don't exit anyone. If the same event should both count as success AND stop reminders, configure the same trigger in both exit AND goal.
• Child-record + repeat-entry trap: Contact A has 3 child records, repeat entry allowed → they're in the journey 3 times. An exit trigger firing once pulls them out of all 3 instances unless the trigger carries a bindingId identifying the specific instance. For consent withdrawal that's correct behaviour. For per-record reminders ("your service appointment is in 3 days"), it's a bug — one cancellation kills the reminders for the other two appointments.
• Narrow exit triggers with conditions — e.g. the OOB Event Registration Cancelled exit is narrowed with an event-reference condition so only the matching event cancels the journey. Whether you can dynamically compare the exit trigger's record id against the starting trigger's record id (rather than a fixed value) is version-dependent — build a throwaway journey in INT and confirm before committing.
• Boolean composition workaround: no AND/OR composer across triggers/segments. For OR across triggers: create one custom trigger raised from a Power Automate flow that encapsulates conditions. For AND: push the logic into the segment definition itself — dynamic segments can express arbitrary conditions internally.
• Bulk-load trap: triggers fire when a record is manually updated in Dataverse, not just when a customer does something. A KingswaySoft bulk update touching a child table or Contact table can mass-enter or mass-exit people from live journeys. Microsoft lists this as a known issue with no suppression toggle. Deactivate trigger-based journeys before any bulk load on tables those triggers watch.

Learnings / how to apply

• Codify the "exclusion segment + exit segment + consent-field trigger" triplet as the Praxisis CASL compliance pattern for CIJ consent withdrawal.
• Document the bindingId requirement in the Sustain Operating Model's CIJ troubleshooting runbook — it explains an entire class of "customer complaint: they got cancelled too eagerly / not eagerly enough."
• Pre-flight "deactivate trigger journeys before bulk load" as a mandatory step in any Praxisis data-import runbook — one of the quietest ways to generate 100,000 duplicate emails in a nonprofit tenant.

---