Transaction ID in Post-Login Actions Available in Additional Login Flows

The event.transaction.id field in the context of post-login actions is available for additional login flows. In particular, when post-login actions execute as part of browser-based login flows, a transaction identifier value will consistently be available in this field.

Previously, the field could be incorrectly undefined for a specific subset of these transaction types, for example, in Single Sign-On (SSO) scenarios, where the flow can skip the login stage due to an existing authenticated session.

Although not documented as an expected system behavior, the observable outcome of having a transaction identifier for flows where the user completes the login stage, versus the lack of a transaction identifier in login flows that leverage an existing authentication session, could have led to post-login actions implementing conditional logic based on the availability of this field.

Post-login actions that make logic decisions based on the existence of a transaction identifier may exhibit unexpected behavior due to the field containing a value in scenarios where it was previously undefined.

• Actions

The service changed the behavior of the event.transaction.id field in post-login actions as part of a calendar year 2025 scheduled change to enable leveraging the field for additional use cases in post-login actions that handle browser-based login flows and require a consistently available unique identifier.

Tenants identified as having post-login actions referencing the field maintained the original behavior for an extended period and received multiple notifications about the planned change between June and December 2025. Starting in January 2026, those remaining tenants transition to the new behavior, and a transaction identifier will be available in additional scenarios.

Post-login actions that use the event.transaction.id field to distinguish between authentication transactions, including those with a login stage, versus those that leverage single sign-on, must use alternative approaches. For example, consider the methods listed in Differentiate User Logins From Session Reuse (SSO) in Post-Login Actions.