Tines Academy › Lesson
Understand the production path
Pushing live is when a workflow starts running for real. Learn what protects a workflow on its way from draft to live, what a test can still reach, and how five questions help you decide whether it's ready.
Objective: Explain what protects a workflow on its way from draft to live, and decide whether a workflow is ready to push live.
The moment that matters most
You now know how to check a workflow, what to watch, who can do what, and how far a connector should reach. All of that comes together at one moment: pushing a workflow live.
Drafts keep changes separate from the live version, so you can build and test without replacing what your team is using today. What a draft doesn't do is make your tests pretend. If a step uses a production connector, a test can send a real message or change a real record, so choosing your test data and destinations is part of building.
Pushing live changes something else. From then on, this is the version that runs when something starts the workflow: a schedule, a submitted page, an incoming request. Nobody has to run it for it to happen, and what it does, it does for real.
By the end of this lesson, you'll be able to explain what protects a workflow before and after it goes live, and decide whether a workflow is ready.
People operations has built a new-hire onboarding checklist: a manager fills in a page, and the workflow creates onboarding tasks in the team's project tracker. Let's step through what protects it at each stage, and what doesn't.
From draft to live
Five questions before you push live
Tines 3B handles the mechanics of going live safely. Whether a workflow is ready is still a human decision, and these five questions are how you make it.
Has it been tested on realistic information? A test that finishes without an error tells you no error was reported. It doesn't tell you the result was right, and placeholder details won't tell you how the real system responds.
Does it reach the right tools? Its connectors should point at the real systems it's meant to use, scoped to the job the way you practiced in the connectors lesson.
Are the right people in control? Check who can see and change its space, who decides what it does, and who can open its page or call its API endpoint, if it has one.
What happens when something's missing or wrong? Try at least one edge case before real users do.
Who's watching it afterward, and what will they do? Someone should own checking its runs and health. How often depends on what a failure would cost: a Monday check is fine for a weekly summary and nowhere near enough for customer emails. Decide who notices, what they do to stop the damage spreading, how it gets fixed, and who tells the people affected.
Run a readiness check
Choose a workflow that's still on a draft, such as the one you built in Fundamentals. First gather the evidence, then use it to answer the five questions.
Open the workflow and check the branch selector to confirm you're looking at a draft.
Open the detailed view of a step you tested and look at what it used. Were those realistic details, or placeholders? If you tested the whole flow and that run appears in the Runs tab, open it there too.
Check whether any test used missing or unusual information. If none did, that's your answer to question four.
Note which connectors the workflow uses, if any, and who else can see and change the space it lives in.
Answer each of the five questions in one sentence: ready, not ready, or not sure yet.
A "not sure yet" is useful. It tells you exactly what to check before anyone pushes live.
After you choose, check yourself against the five readiness questions. Which one would have caught this?
What to do if something still feels fuzzy
A draft keeps your changes separate from what your team is using, but it doesn't stop a test from reaching a real system, and deciding whether a workflow is ready is still a human call. The five readiness questions help you make it. Next, you'll turn your decisions into a plan your teams can follow.