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. Here is a typical starting request.
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; the event and criteria still need review.
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.
Proposed 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.
Confirm the activity choices against the target Latitude environment.
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.
The final check compares observed behavior with the approved process.
A clearer path from request to workflow
See how Native separates the trigger, business rule, activity design, and proof.
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.