Creates a message used to pass information between different journeys.
Cross-session messages allow different journeys to securely share info without exposing it to the client, and allow creating dependencies between the flows. For example, a journey can share the user context with another journey, or put the journey on hold until another journey completes a certain step.
This step creates the message as a JSON object using content that's evaluated at runtime, and also generates the message identifier (ticket ID). The ticket ID can then be provided to other journeys so they can read, update, or process the message. You can also add a step to the current journey that pauses the flow until the message is processed, and may receive additional info from the processing journey. After creating the message, you can use the Update Cross-Session Message step to update the shared data or extend the message expiration before it is processed by another journey.
Typically, this step is followed by a Wait for Cross-Session Message, which pauses the current journey until another journey processes the message and returns the result. After the message is created, the parallel journey can use the Process Cross-Session Message step to read and process it.
| Field | Description |
|---|---|
| Cross-session message request fields | A list of key-value pairs used to create the message content. The key is a parameter name and the value is an expression that yields the parameter value at runtime. |
| Output variable | Name of the variable used to store the message ID, the unique identifier of the cross-session message created by this step. Use this variable to provide the ID to another journey to read and process the message content, or to wait for the message to be processed. Default is cross_session_message. |
| Enable expiration timeout | Select Yes to only allow the message to be processed within a specified period of time from when it was created. Default is No. |
| Expiration timeout | Period of time (in seconds) within which the message can be processed, counted from when the message was created. This field is only evaluated in runtime. Note: Since the database will purge all messages after 3 days, the timeout cannot effectively be greater than 259,200 seconds, regardless of the configured timeout. |
| Enable consuming user restriction | Enable to process the cross-session message in the context of a specific user. |
| External user id | Defines the user context for consuming the message. - For authenticated users, this can be an expression containing an external user id (e.g., @policy.userContext().external_user_id).- If the user hasn't authenticated, the external user id can be set in a variable. |
| Enable reading user restriction | Enable to read the cross-session message in the context of a specific user. |
| Ticket identifier type | Format of the generated message ID, which can either be a generated UUID or a case insensitive alphanumeric string of a specified length. Note: The alphanumeric option is only supported for MongoDB. |
| Identifier length | Number of characters generated as the message ID, for the alphanumeric format. |
This step can be configured to record step input and output data, or a custom payload, which is then surfaced in journey events in Journey Analytics for diagnostic purposes. For details, see Additional data reporting.
Assume a journey is running on a desktop device, and at a certain point, a cross-device handoff to a mobile device is required. Using the Create Cross-Session Message and Wait for Cross-Session Message steps, the journey creates a cross-session message and then waits for cross-session message from another journey. See Cross-device face authentication as an example of the flow leveraging cross-session messages.
