Enterprise journeys rarely stay inside one web application. An order placed in a storefront appears in an order-management system and again in a finance tool. A new starter created in an HR system shows up in a directory, a payroll application and a ticketing tool. Each of those applications is probably tested by a different team, and the seam between them is exactly where things break and nobody notices.
This page is how to cover those journeys with Studio without building something unmaintainable.
First, decide what you are actually proving
A cross-application test is expensive to build and expensive to keep. Write down what a red result would be telling you before you build it, because that determines the shape.
| “The hand-off works” | The record created in A arrives in B, correctly and within a sensible time. This is the valuable one, and the one nobody owns — team A tests A, team B tests B, and the gap between them is tested by production. |
| “The whole journey works” | End to end, every step, all three systems. Satisfying to demonstrate and painful to maintain, because it goes red when any of the three has a bad day and the red tells you almost nothing about which. |
| “Each system works” | What you already have. Necessary, and it will not catch a hand-off failure. |
Build the first one. Keep the third. Be very deliberate before building the second, and if you do, keep exactly one of them as a demonstration rather than a suite.
The shape that works: one project per application, one orchestration per journey
This is the whole pattern, and it is worth stating plainly because the instinct is usually to build one enormous test.
- A project per application. Each carries its own access, auth, cookies, timeouts and browser behavior — because each application needs different ones. Each is owned by the team that owns that application.
- A test per leg of the journey, inside the project for the application that leg happens in. “Place the order in the storefront.” “Confirm the order appears in order management.” “Confirm the invoice is raised.”
- An orchestration for the journey, pulling those tests together and running them in order as one job.
What you get from that: a red result names the leg that failed, so it routes to the right team without anyone triaging it. Each leg keeps the settings its own application needs. And each leg is independently useful — the storefront test is a good test on its own.
What you give up: the legs do not automatically share state. Which brings us to the hard part.
The hard part: carrying a value between applications
The order number created in leg one is the thing leg two needs to look for. Three ways to handle it, in order of preference.
1. Make the value predictable
The most robust answer, and the one people reach for last. Have the test create a record it can identify without being told — a customer reference it generated, a unique name, a value derived from the run. Then leg two searches for that, and no hand-off is needed at all.
Where your application will accept a supplied reference, use one from an execution preset variable. See Test Data: Execution Presets, Variables and Secrets.
2. Capture it and hand it on
A step can capture a value — an order number, a generated reference — and a later step can use it. Those runtime values appear in the Variables tab under the browser pane, so a broken hand-off is visible rather than mysterious. Check it there rather than assuming.
3. Fetch it with an extension
When the value only exists somewhere the browser cannot see — a queue, an internal API, a mailbox — an extension runs your own code in Node, Python, Go or Java inside the test. That is what they are for. See Extensions: Running Your Own Code Inside a Test.
For a one-time passcode delivered by email, the built-in reader handles
@functionizeapp.com addresses; give the test account one of those and read the code
back.
Timing across systems, which is where these tests actually fail
The hand-off is usually asynchronous. A queue, a batch, an integration that runs every two minutes. A test that checks system B immediately after system A will fail intermittently forever, and intermittent failure is how a suite stops being read.
- Describe the state you are waiting for, not a duration. “Wait until the order appears in the list” survives a change in how long the integration takes; “wait 30 seconds” does not.
- Raise the missing element timeout at project level on the receiving application, where the wait actually is.
- If the hand-off genuinely takes minutes, do not hold a browser open waiting for it. Split it: one orchestration confirms the record was created, a later scheduled run confirms it arrived. Two honest results beat one flaky one.
Reuse the parts that repeat
Across several applications you will log in dozens of times. Build each login once as a reusable component and call it by name — the Add component control sits in the steps pane toolbar. One place to fix when an authentication flow changes, and materially fewer credits than regenerating the same journey inside twenty tests.
What to do about the system you do not control
Most enterprise journeys touch something nobody on your side owns: a payment provider, a partner portal, a third-party identity provider.
- Use its sandbox where one exists, with a preset per environment so the same tests point at sandbox or production credentials without editing a step.
- Stop at the boundary where it does not. Prove your side handed off correctly, and prove you handle the response correctly, as two separate tests. Testing somebody else's uptime teaches your team to ignore red.
- Ask us if a journey depends on email, SMS or a system you cannot reach. This comes up constantly and there is usually an approach.
If an application is not on the public internet
Studio runs in our cloud, so it needs to reach the application. For internal systems, Quickconnect is the answer — see Functionize Quickconnect (ACS Quickconnect). Establish this before you design a cross-application journey, because it decides which legs are possible.
A worked shape
An order journey across three systems, as it would actually be built:
| Project: Storefront | Test 1 — place an order as a guest using a generated customer reference; confirm the confirmation page shows an order number. |
| Project: Order Management | Test 2 — search for that customer reference; confirm exactly one order exists, with the expected total and status. |
| Project: Finance | Test 3 — search for the same reference; confirm an invoice exists for the expected amount. |
| Orchestration: Order journey | All three, in order, nightly. Owned by whoever owns the journey rather than any one application. A red result names the leg. |
Note what carries the journey: a generated customer reference, not a captured order number. That is the choice that makes it robust.
Where to go next
- Exercise 6 - Group Tests Into an Orchestration — the mechanics, on the demo store.
- Keeping a Suite Green: Flake, Tiers and Who Owns Red — cross-application tests belong in a tier, and it is rarely smoke.
- Scaling From One Team to Many — who owns a journey that crosses team boundaries.