Problem

In trigger-based journeys, the entry trigger object — including all its custom attributes — is fully accessible as a personalization source in the email editor. However, when a custom trigger tile fires a Power Automate flow, that flow only receives what has been explicitly defined as custom attributes on the trigger and manually mapped in the tile. The full entry trigger object of the journey is not automatically available in the flow, even though it is present and used by the journey runtime throughout execution.

This creates an asymmetry: the email editor and the journey canvas both have automatic access to the entry trigger context, while Power Automate — the integration layer most likely to need rich business data — does not. Developers work around this by manually defining individual attributes on every custom trigger and re-mapping them in every tile, which is repetitive, error-prone and hard to maintain as requirements evolve.

Illustrative example

A journey is triggered when a new Occasion record is created in Dataverse. The trigger carries an entity reference to the Occasion itself and a campaign record. Both are needed to create a phone call activity in an external system via a downstream custom trigger tile backed by a Power Automate flow.

Today: the developer must define two explicit attributes on the custom trigger (OccasionId, CampaignId), then open the custom trigger tile and manually map each one from the entry trigger context using the personalization picker — for every journey that uses this pattern. If a third field is needed later (e.g. a due date), all affected tiles across all journeys must be updated individually.

With this feature: the Power Automate flow would receive the full entry trigger object automatically as an additional input. The flow could directly read OccasionId, CampaignId, and any future attributes without changes to the journey configuration. Explicitly defined custom trigger attributes would remain fully supported alongside this — for values that do not originate from the entry trigger, such as computed values or data added at a later stage in the journey.

Proposed solution

When a custom trigger tile fires a Power Automate flow within a trigger-based journey, the flow should automatically receive the journey's entry trigger object as an additional input — alongside the already-available customer profile ID. This is analogous to how the email editor exposes the entry trigger context for personalization, adapted to the structural input model of Power Automate flows. Developers would be able to reference entry trigger attributes directly in the flow without needing to declare and map them as explicit custom trigger attributes first.

Why this is feasible

The entry trigger payload is already available to the journey runtime — it is used to evaluate conditions, drive attribute branches, and populate email personalization. The mechanism for passing trigger data to Power Automate already exists (custom trigger attributes are passed as ActionInputs in the Dataverse action). Extending this to include the entry trigger object automatically is a natural and minimal addition to the existing infrastructure, consistent with how other journey components already work.

Expected benefits

Reduced configuration overhead

Entry trigger attributes that are already part of the journey context no longer need to be re-declared and re-mapped at every custom trigger tile. Explicitly defined attributes remain fully supported for any data that goes beyond the entry trigger context — this feature extends the model, it does not replace it.

Faster journey development

Journey builders no longer need to anticipate upfront which entry trigger fields a downstream flow might need. New fields added to the trigger schema become immediately available in all connected flows without any tile-level changes, significantly reducing the time and risk involved in evolving existing journeys.

Richer process automation

With the full entry trigger context available, Power Automate flows can implement more sophisticated, data-driven logic without being constrained by what was manually forwarded from the journey. This unlocks a level of personalization in custom trigger processes that is currently only achievable through significant additional configuration effort.

In summary: this feature would bring Power Automate flows closer to parity with the email editor in terms of journey context access — closing a gap that currently forces developers into manual workarounds for something the platform already supports in other components.