Subchapter 19.18

Validation And Verification

references/automations/validation-and-verification.mdMarkdown30 KBView on GitHub

Email configuration prerequisite

Check first: Follow Email configuration in Automations API Catalog (opens in a new tab) before email-action/schema/provider calls or writes.

No complete guide: References to the legacy email exclusion (“Later stages only”) mean these calls and writes are excluded while no loaded index/reference links the complete Automations Email Actions guide.

Complete guide linked: Load it and perform only its documented operations, subject to existing permissions, validation and consent requirements.

Validation And Verification · Wix Manage · wix/skills · Skills Docs

§4 checklist passes and the final full Validate is VALID (or understood warnings).
Create Automation with origin: "USER", configuration.status: "INACTIVE", no settings. Capture id. Send Create as its own call, after a separate full Validate call has returned VALID (or understood warnings) — never in the same script as that Validate or as discovery. Send it once per candidate: if a Create’s outcome is unknown, Query Automations before resending it (Reporting rules below). A Create that was never sent is not an attempt.
Read back with Get Automation on the same site. Confirm the trigger, the root id, and the set of action ids/types match what you sent (string literals come back URI-encoded, as sent). If you used an override schema, Get with fields: ["OVERRIDE_SCHEMA"] (Automations API Catalog (opens in a new tab) §2). Run the Get as a separate call once Create has returned (not batched into the same script), and retain the returned automation as the evidence. Show its requested fields or the verifiable comparisons described above; a selected summary that omits them is insufficient. For a small automation, return the complete already-fetched object from the API caller instead of rebuilding a projection. Here getBody is the parsed successful Get response:
```
return { automation: getBody.automation };
```
This retains message-field mappings, conditions and settings as evidence without another Get. For a larger object, keep the full response locally and return comparisons computed from its actual fields; do not substitute the submitted candidate.
Hand off, leading with the outcome. Make the first line of your answer the saved state, for example: “Saved as inactive (ID <automationId>). Click Activate in the builder to turn it on: https://manage.wix.com/dashboard/<metaSiteId>/triggers/edit/<automationId>“. That first line MUST name the automation, its status and its ID together; don’t move the ID to a later line, because a reader may see only the first line. Then say what it does, and ask the user to review it in the builder. If the user asked to turn it on, activate it first (step 5) and make the first line the active state instead: “Saved and turned it on (ID <automationId>): “.
Activate only on request — see “Activation status, activate, deactivate” below.

Get Automation with fields: ["OVERRIDE_SCHEMA"] so a complete-object update preserves trigger/action override schemas. Check origin and settings locks (§ Update restrictions above) before planning any change.
Retain a complete before snapshot, then change only what was asked on a separate copy. Keep ids and the complete contents of untouched nodes.
§4 checklist + full Validate on the merged object.
If the automation is ACTIVE, the update goes live immediately — say so and get confirmation first (consent rules: § Update restrictions above).
Update with the whole merged automation, the revision you read, and origin + settings exactly as fetched (else INVALID_ORIGIN_TYPE, even with a field mask — Automations API Catalog (opens in a new tab) §2). On a revision conflict, re-Get, re-apply, re-validate.
Capture the returned automation’s id — the first override of a preinstalled automation can have a new id. Get that id with overrides. Compare the complete returned fields with the intended merged object, and every untouched field with the before snapshot: name, status, origin/settings, trigger, roots, and each existing node’s namespace, display name, mappings, schemas and other metadata. Ignore only server-managed revision/timestamps/last-updater audit and a confirmed override ID change; object key order is immaterial, array order and value types are not. For an appended node, allow only that new node and its intended attachment edge to differ. Return the relevant fields or explicit comparisons computed from the actual Get response; surviving IDs and a title/edge summary do not establish preservation. If a comparison fails, report the mismatch instead of claiming the edit is verified. A bumped revision with old content means the update did not apply — re-send with fieldMask: configuration,name and verify again.
If the change makes the automation’s name or a step’s displayName inaccurate (e.g. “…1 day…” after the wait became 2 hours; “Add VIP label” now adding another label), offer new names; rename only with their OK.

// Saved update comparison
function verifySavedUpdate(intended, afterGet) {
  if (
    !intended?.id ||
    afterGet?.id !== intended.id ||
    !intended.configuration ||
    !afterGet?.configuration
  ) {
    throw new Error(
      'Missing successful complete Get or mismatched automation ID'
    );
  }
  const ordered = value =>
    Array.isArray(value)
      ? value.map(ordered)
      : value && typeof value === 'object'
        ? Object.fromEntries(
            Object.keys(value)
              .sort()
              .map(key => [key, ordered(value[key])])
          )
        : value;
  const comparable = ({
    revision,
    createdDate,
    updatedDate,
    updatedBy,
    ...fields
  }) => ordered(fields);
  const matches =
    JSON.stringify(comparable(intended)) ===
    JSON.stringify(comparable(afterGet));
  if (!matches) throw new Error('Saved fields differ from the intended update');
  return {
    automationId: afterGet.id,
    status: afterGet.configuration.status,
    completeSavedFieldsMatch: matches,
  };
}

const intended = structuredClone(before);
Object.assign(intended.configuration.actions[delayId].delayInfo, {
  offsetExpression: requestedOffsetExpression,
  offsetTimeUnit: requestedOffsetTimeUnit,
});
// After separate successful Validate, Update and Get calls:
const verification = verifySavedUpdate(intended, afterGet);

Validation And Verification

Validation And Verification

1. Local checks and semantic review

2. Validate Automation

Error types → fix

Fix loop

3. Persistence, read-back and honest reporting

Create

Update restrictions

Update

What happens when the user opens it in the builder

Activation status, activate, deactivate

Reporting rules

4. Builder-renderability checklist — the single pre-save gate

5. Test Automation — only with explicit authorization