Use Cotonity's test mode, trigger simulator, and execution log to find and fix bugs before going live, and safely iterate on active workflows using version drafts.
The Importance of Testing Before Activation
Activating an untested workflow against real production data is one of the most common mistakes new automation practitioners make. A misconfigured field mapping might silently overwrite correct data in your CRM with blank values. An incorrect condition might cause thousands of emails to be sent to unintended recipients. A missing error handler might leave records in a half-processed state that is difficult to clean up. Cotonity's test mode lets you run the full workflow end-to-end against sample data without touching production systems. All external API calls, emails, and Slack messages are intercepted and logged rather than actually sent. Use test mode for every new workflow and for every significant change to an existing one before reactivating it.
Using the Trigger Simulator
Every trigger type in Cotonity includes a built-in simulator. For webhook triggers, the simulator lets you paste a sample JSON payload and click 'Run Test' — the workflow executes as if that payload had arrived via an actual HTTP request, but all outbound calls are mocked. For schedule triggers, the simulator fires a test execution immediately rather than waiting for the next scheduled time. For platform event triggers, you can publish a test event directly from the trigger settings panel. Build a library of realistic sample payloads for your most critical workflows — edge cases like empty optional fields, unusually long strings, and Unicode characters — and run the simulator against each one regularly, particularly after making changes to upstream systems that produce the trigger payloads.
Reading the Execution Log
Every workflow execution — test or live — produces a detailed execution log accessible from the Runs tab. Each entry in the log shows the execution ID, trigger timestamp, duration, final status (success, failed, or timed out), and a step-by-step breakdown. Click on any step in the breakdown to see the full input context it received, the output it produced, and the duration it took. When debugging a failure, start by identifying the first step whose status is 'Failed' or 'Skipped unexpectedly', then examine its input to check whether an upstream step produced an unexpected data shape. The most common root causes of workflow failures are null reference errors (a field that was expected to exist is missing from the payload), type mismatches (a numeric comparison applied to a string), and authentication errors (a connection token expired).
Iterating Safely on Live Workflows
When you need to update a workflow that is actively processing production traffic, use Cotonity's versioning feature rather than editing the live workflow directly. Every published workflow has a version history accessible from the Settings → Versions tab. Click 'Create draft' to open a copy of the current workflow in edit mode; your changes do not affect live executions until you explicitly publish the draft. Once your draft is tested and ready, click 'Publish draft' to atomically swap the live version. Executions that were already in-flight when you published continue running against the old version; only new executions pick up the update. If the new version causes unexpected problems, roll back in one click from the version history panel by selecting the previous version and clicking 'Restore as live'.