Prepare your first verified workflow

Begin with one application and one workflow whose expected behavior your team can describe. Identify the application owner, the people who will operate Zof, and the reviewer who will decide whether the first results are useful. Define the environment, release or version, and a small set of acceptance criteria before configuring automated work.

An initial evaluation should answer a concrete question: whether a critical user journey completes, an API respects a contract, or a known defect can be reproduced. Record the existing test result or manual procedure as a baseline. Deployment preparation and access reviews can affect timing, so agree a schedule that reflects your environment.

Confirm your deployment model and the organization, project, and application scope you are authorized to use. Ask your administrator to verify roles, identity configuration, and any network access required by the selected execution agents. Follow the configuration supported by your subscription and deployment.

Use a staging environment and synthetic or approved test data for the first run. Agree which credentials may be used, who can rotate them, and where secrets must be stored. Do not paste credentials into requirements, screenshots, support messages, or test descriptions.

Create or select the relevant project and application, then add the requirements or specifications for the agreed workflow. Review generated scenarios and test cases for correctness, scope, data use, and environmental assumptions. Confirm the agent assignment and permissions before execution.

Run the smallest useful test first. Inspect the result, evidence, and error details against the agreed expectation. A completed run is not the same as a successful business outcome: investigate skipped work, missing assertions, environment failures, and any result that cannot be reproduced.

After the first run is understood, agree who may change the configuration, how results are reviewed, and what happens when a run fails. Add scheduling or CI/CD integration only after confirming the impact of retries, credentials, capacity, and any release gate that will depend on the result.

For remediation, define the approval boundary before permitting changes. Review the proposed change and its verification evidence using your organization’s change-management process. Keep a record of the configuration, reviewers, acceptance decision, and unresolved limitations.

Give the operational owner a short runbook covering the environment, authorized users, normal workflow, expected evidence, and escalation steps. Document what has been evaluated and what remains outside scope. Review access and data handling before expanding to additional applications.

If you need help, include the organization and project identifier, relevant run identifier, timestamps with time zone, the expected outcome, and the actual error. Remove sensitive content before sending logs. Support channels, hours, and response commitments are determined by your agreement.