StarHash Documentation

Testing a workflow before publishing

Test a workflow and check its behaviour before publication.

Testing helps confirm that a workflow behaves as expected before customers use it. Test every main path, every exit path, and any screen that calls another system.

Use this guide before publishing a workflow.

What to test

Test the workflow from the customer's point of view.

Check that:

  • The first screen is correct.
  • Menu text is clear.
  • Each option goes to the expected next screen.
  • Customer input is accepted where expected.
  • Terminal screens end the journey.
  • Dynamic menu options load correctly.
  • Error paths show useful messages.

If the workflow uses a short code, confirm that the correct short code is assigned before publishing.

Test common paths

Start with the most common customer journey.

For each path, write down:

  • The option selected.
  • The screen that appears next.
  • Any data entered by the customer.
  • The final message shown to the customer.

This makes it easier to spot missing links or confusing prompts.

Test edge cases

After the happy path works, test less common behaviour.

Examples:

  • Selecting an option that should exit the session.
  • Entering a value in the wrong format.
  • Reaching a menu with no available dynamic options.
  • Following each branch from the first menu.
  • Ending the session from different points.

Edge-case testing is especially important before publishing changes to an existing workflow.

Test dynamic menus

For dynamic menus, use the source test tool in the editor.

Check that:

  • The request succeeds.
  • The response contains the expected list.
  • The template maps the list correctly.
  • Generated option labels are readable.
  • Generated option values are stable enough to use later in the journey.

If the dynamic request uses values captured earlier in the session, test with realistic sample values.

Review session results

After a workflow has been used, session data can help confirm how customers moved through the flow.

Use sessions to review:

  • Completed and incomplete sessions.
  • Average number of hops.
  • Where customers exit.
  • The detailed hops recorded for a session.

Session review is useful after publishing, but it can also help during controlled testing.

Pre-publish checklist

Before publishing, confirm that:

  • The workflow is saved.
  • The workflow has a short code.
  • The main customer journey works.
  • Alternative menu paths work.
  • Terminal screens end cleanly.
  • Dynamic menus generate expected options.
  • Any validation or compile errors have been resolved.
  • A short change summary is ready for the publish step.

On this page