nativeWorkflowStart with the process.
Find the path to a working Latitude Workflow.
Native helps turn a business request into a reviewable event, decision, and activity plan. The first win is seeing the paths and the questions that matter before building and testing in Latitude.
A request in everyday language
Imagine an operations team describes the behavior they want. The example below is invented for this walkthrough.
See the workflow before building it.
- Find the real triggering event.
- Make each condition and path explicit.
- Reuse known activities where they fit.
- Ask only questions that change behavior.
- Prove the expected result in a test environment.
Explore the four steps
Each step adds certainty. Select one to see what a reviewer would inspect and what still needs an answer.
Find the event and all paths
Turn the request into an explicit trigger, eligibility decision, action path, and skip path. Check what information the event actually makes available.
Proposed process inventory
This is a proposed interpretation of the fictional brief, not a confirmed Latitude configuration.
Questions worth finding now
What exactly counts as a new account? What makes it eligible? Which account or placement data are available when the event fires?
Native can organize the paths; the actual business criteria still need evidence or an explicit decision.
Resolve the rule before wiring activities
“Eligible” could mean a status, a customer-specific flag, an account property, or a combination. Native should propose hypotheses and show the evidence behind them rather than inventing a threshold.
Example semantic trail
The question marks matter. A condition that compiles can still select the wrong accounts.
One material decision
“If the account qualified yesterday but no longer qualifies when the workflow runs, which state should control?”
That answer affects timing, repeat behavior, and the tests needed before approval.
Choose the right event and activities
Use the reviewed activity catalog and the target Latitude environment to choose supported building blocks. Show the branches, required inputs, and exception handling before proposing installation.
Illustrative activity plan
Where Tribal helps
Shared Latitude knowledge explains event and activity behavior. Customer-specific configuration can refine the choice when available. Neither replaces a decision about this customer’s intended process.
The pictured plan is illustrative; no Workflow XML or supporting code has been generated here.
Prove each path, not just the workflow file
Run controlled cases in a test Latitude environment. Compare what the workflow actually did with the approved process, including the skipped and repeated paths.
Expected versus observed
Evidence that travels with the build
Keep the original request, approved interpretation, generated artifacts, test inputs, execution record, observed state, and remaining differences together.
This walkthrough describes an acceptance method. It does not report a completed customer workflow test.
A clearer path from request to workflow
The walkthrough shows how Native would separate the trigger, business rule, activity design, and proof. It is an interactive explanation, not a live workflow generator.
The actual Latitude behavior
Available events and activities, customer configuration, permissions, timing, and correct outcomes depend on the target environment. Those are reviewed and tested before a workflow is called ready.