Before you go live

Compiling a Journey proves that its XML is valid. It does not prove that your adapted process behaves correctly for your users and data. Before publishing a Journey, and again after changing a published one:

• Run server analysis against the instance you are publishing to, so every GraphQL field, variable and capture path is checked against its actual schema.
• Walk every conditional path with representative data, including the branches a typical user rarely takes.
• Sign in as a user who lacks permission for each write, and confirm the Journey reports the refusal clearly. Check that mutations ask for confirmation.
• Force a failure on each fetch and execute stage, then retry it. Confirm a retried create cannot produce a duplicate record.
• Go back to earlier stages, change answers, and advance again. Check that later stages and the completion text reflect the new answers.
• Check completion text with empty values, non-English text and text that looks like markup; it must display literally.
• Keep journey and step IDs stable. If users may have runs in progress, check they still resume correctly after the change.

The examples in this manual are starting points. Their API fields are illustrative; the checks above belong to your particular business process.