Trades to Sheets
Confidence by Design: Understanding Regular, Force Run and Test Run
The evolution of automated workflows often hits a common snag: the tension between system integrity and user flexibility. In our latest architectural update, we’ve introduced the "Test Run" to complete a triad of execution types.
This deep-dive explores the technical philosophy behind these three modes and why separating "testing" from "state" is a game-changer for operational confidence.
The Core Conflict: Determinism vs. Discovery
At the heart of our system lies the Plan Hash. Think of this as a digital fingerprint. When a task runs, the system records this hash to ensure we don’t process the same data twice. This "idempotency" is what keeps your production environment clean and prevents duplicate records.
Comparison of Execution Modes
| Feature | Regular Execution | Force Run | Test Run |
|---|---|---|---|
| Trigger Mechanism | Automated (System-led) | Manual (User-led) | Manual (User-led) |
| Plan Hash Generation | Yes | Yes | No |
| Primary Intent | Normal work flow; avoids duplicated inserts automatically. | Trigger action immediately within a regular window. | Tweaking operations to see results instantly. |
| UI Access | None (Background process) | "Plans" > Action Menu or "Plan Detail" > Action Menu | "Plan Detail" (Next to "Save" Button) |
1. Regular Execution: The Silent Engine
Regular Execution is the "set it and forget it" mode. It is designed for hands-off reliability.
The Philosophy: Automation should be invisible.
The Guardrail: It relies heavily on the "Plan Hash". If the system sees a task that has already been hashed, it skips it. This prevents the "double-insert" nightmare that plagues automated databases.
2. Force Run: The Manual Override
Sometimes, the real world doesn't wait for a scheduled window. Force Run allows you to pull a production action forward.
The Philosophy: Give the user control without breaking the rules.
The Guardrail: Because this is still a "Production" action, it generates a hash. If you "Force Run" a task now, the Regular Execution will see the hash later and know not to repeat the work. It is a manual trigger with permanent consequences.
3. Test Run: Challenging the Status Quo
The Test Run is our response to the "Fear of the Big Red Button." Historically, if a user wanted to see if their new configuration worked, they had to run it for real and then manually clean up the "test data" or "duplicate hashes" it left behind.
Why did we build it this way?
We built Test Run to be stateless. By intentionally not generating a Plan Hash, we allow you to: Iterate Rapidly: Tweak a parameter and run it again instantly. Verify Without Pollution: See the result of an operation without the system "marking it down" as completed.