Production Validation & Change Control
A working sample transfer proves that one file followed one path under one set of conditions. Before relying on the deployment, verify its access boundaries, delivery evidence, failure response, and configuration ownership. Repeat the consequential checks when those conditions change.
Build One Representative Flow
Use test data and isolated destinations to exercise the same connection types, account permissions, file patterns, and processing stages intended for production. Check the actual host, account, and folder for every Remote Server. A connection in a test Workspace or Child Site can still reach a production system.
Test with ordinary users and the real execution identity. A Site Administrator's successful manual transfer does not prove that a Partner User, machine account, or user-owned Automation has the necessary access. Include file replacement and cleanup if the workflow performs them.
A Sync dry run helps inspect selection without transferring files. Follow it with a controlled live test: a dry run does not establish that the destination accepts the actual write or that the receiving application can import the result.
Validate the Result and the Failure Response
| Test | What to establish |
|---|---|
| Valid representative input | The intended output reaches the intended destination and passes the receiver's checks |
| Missing or late input | Monitoring identifies the absence and reaches the responsible operator |
| Invalid content | The process reports or isolates the problem without unintentionally releasing it |
| Unavailable destination or expired credential | Failure is visible, retained input is recoverable, and the retry procedure is understood |
| Partial or uncertain delivery | The operator can distinguish completed work from work that needs replay |
| Repeated delivery or corrected file | Overwrite, duplicate handling, and downstream effects match the agreed contract |
| Unauthorized account | Unrelated files and administrative actions remain inaccessible |
Review the delivery evidence for each stage. Confirm notification delivery as well as event creation. Include likely operational changes, such as staff offboarding and credential rotation, when testing ongoing ownership.
Choose a Configuration Authority
The CLI executes actions: upload a file, create a user, or change a setting. Terraform describes configuration and uses state to plan changes to managed resources. Choose the method that fits the resource's lifecycle.
Both can serve one deployment. Terraform might manage folder structure and permissions while a CLI script delivers daily files. They can also conflict if both change the same managed resource. Assign one configuration authority per resource, and reconcile an emergency manual change with that authority before the next deployment.
For Terraform, import existing resources before managing them, keep environment configuration and state separate, protect sensitive state and plan files, and review the production plan. Changing an old state file is not a way to undo actions on the live site. Follow Terraform Best Practices for the supported workflow.
Review Shared Dependencies
Before changing a Remote Server credential, Schedule, Holiday Calendar, group permission, or site policy, identify what else uses it. A Schedule can affect resources across Workspaces. An Automation v1 edit can change its runtime ownership, including edits that look administrative rather than functional.
Review site-wide authentication, security settings, protocol access, and root-folder policy with the people who own those controls. Domain and network changes belong in the same dependency review when they affect clients or connected systems.
Enable Production and Hand It Over
Review production hostnames, paths, credentials, triggers, overwrite and deletion settings, and notification recipients. Coordinate the start with any previous process that handles the same files. Run a controlled first delivery and verify the receiving application's result.
Name the team responsible for changes, credential maintenance, delivery failures, and business rejections. Record where to inspect logs, how to pause new work, which inputs must be preserved, and what can safely be replayed. Reverting configuration does not undo files already sent, deleted, or consumed; the recovery procedure must account for those effects.