Product adoption
Support begins with the selected decision loop, integration environment, Strata posture, control needs, and operational owners.
- Decision-loop clarification
- Integration review
- Launch readiness
Resource
Support
for adopted workflows
Yedron support is oriented around real operations: keeping decision loops observable, useful, controlled, traceable, and ready for careful expansion.
Operational care
A failed action should not become a mystery.
Support follows the same decision record as the operating team, from the triggering event to the action status and outcome.
- Situation
- The workflow opened with its source event and owner.
- Control
- Policy and approval history show why action was allowed.
- Failure
- The target response and retry state are visible.
- Resolution
- Manual review or a safe retry closes the loop.
Illustrative workflow view. Controls and integrations depend on deployment.
Operational care
After launch, support focuses on outcomes, audit evidence, failure visibility, reliability review, and adjustments to rules or workflows.
- Outcome triage
- Issue review
- Reliability improvements
Workflow expansion
New workflows should be added only after the operating loop, controls, data purpose, and measurable outcomes are clear.
- Expansion planning
- Governance review
- Adjacent loop mapping
In practice
Support the workflow through its operating life.
Operational care needs the same context as the team doing the work. Support review follows the situation, control path, action status, and evidence behind the result.
Launch preparation
Review the selected workflow, source connections, data purpose, and responsible owners. Confirm how approvals, failed requests, and manual review will be handled before the loop is relied on.
Issue investigation
Follow a failed or unexpected response through its decision record. Use the target response, attempt history, policy state, and observed outcome to identify the next permitted recovery step.
Careful expansion
Review outcomes and operational feedback before adding adjacent workflows. Define the new data needs, owners, control requirements, and measures rather than extending an existing permission by assumption.
How it works
Make an issue easier to investigate.
A focused support request connects the operating problem to its evidence. Share only the information appropriate for the agreed support channel and access scope.
- 01
Describe the affected work
Identify the workflow, situation or action reference, expected response, and observed behavior. Include timing and the impact on the operating team.
- 02
Review the available evidence
Follow the source event, decision, policy, approval, and action attempt. Determine whether the issue involves integration, authority, execution, or outcome observation.
- 03
Resolve within the control path
Agree the recovery or review step with the responsible owner. Preserve the resolution and any follow-up changes to rules, integration handling, or workflow design.
Common questions
Understand the fit.
Is a response-time commitment published here?
Support scope, availability, escalation routes, and response commitments are agreed for the deployment. Confirm the applicable arrangements with the team before production use.
What should an issue report contain?
The affected workflow and record references, timing, expected behavior, observed result, and relevant failure details. Avoid including credentials or unrelated records in the report.
How is a new workflow added?
Review the adjacent operating decision, its owner, sources, data purpose, action scope, and outcomes. Expansion follows a defined adoption and governance review.
Explore further
See the connected platform.
Start where one workflow needs clearer control.
Adoption starts with one workflow, the systems around it, the approvals it needs, and the outcome your team wants to improve.
Design a decision loop