# 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.