Setup changes
A setup change checks a proposed data-definition change against existing values and the saved work that reads them. Use it when changing a stored field's type or allowed values, replacing evaluated logic, adding a backfill, deleting an attribute, or changing an event's collection contract.
For example, your Customer schema stores planTier as free text. You want a controlled list with free, pro and enterprise. The change must handle existing values such as professional, and the audience that compares them. Review the proposed conversions and campaign effects together before making the new meaning current.
A save can finish automatically after its checks pass. Changes that need a decision appear in Changes. A pending check or reviewed proposal does not prove the schema changed. Application, reopening the space and resuming automation are also separate outcomes.
Find the change
Start from the field or event you intend to edit. Contact and object attributes live under Settings → Schemas → Attributes. Event attributes and bindings live under Settings → Events, on the event's Attributes and Collection tabs.
Saving a structural edit runs setup checks. If a decision is needed, the app opens the relevant review. Reopen it from the schema's Changes tab. The Changes link at the top of Settings → Events opens workspace-wide history. The history lists changes that need a decision, rather than every ordinary name or description edit.
Use Review a batch from Changes when related schema and attribute edits need to be proposed together. Review the whole proposal's affected definitions, not each field in isolation. Reducing the scope can also resolve a review that exceeds its supported input or processing bounds.
Workspace Read permission is required to inspect a change. Write permission is required to propose, review, apply or cancel one. Integration-managed schema and attribute definitions are maintained by their integration; manual editing is restricted.
State the intended business meaning
Before editing, name what the field represents and which system supplies it. Explain units, allowed categories and missing-value behavior. For money, include currency and whether refunds or tax count. For activity, include the event schema, subject, occurrence-time window and schedule.
Then identify the work that relies on it: a saved audience, an email field, a workflow branch, a form or a webhook. Changing professional to pro preserves a category only if those uses still interpret it as the same plan. A count that happens to stay unchanged is not enough to establish that meaning.
Keep stable identifiers separate from display labels. An attribute's key and the schema's type and slug stay fixed. A name change does not rename the property expected by imports, producer payloads or templates. See Attributes and Schemas for those contracts.
Choose what happens to existing values
Changing a stored field offers Existing records policies. The policy is part of the proposed change, not a later cleanup task.
| Policy | Result | When it is useful |
|---|---|---|
| Keep existing values | Preserve each value and check it against the proposed rules | Widen a bound or add an option without rewriting values |
| Fill empty values | Fill missing or empty values with one chosen constant | Give old records a deliberate known fallback |
| Map specific values | Replace exact values using explicit pairs | Consolidate Pro and professional into pro |
| Convert to the new format | Normalize values against the proposed type and rules | Convert compatible numeric text into a number |
| Replace all values | Replace the attribute on every existing record | Deliberately reset a field, including populated records |
For a value map, choose Values without a mapping: Keep unchanged, Convert to the new format, or Block this change. An unchanged value still has to fit the new rules. An unmapped category should block the change when silently carrying it forward would misclassify customers.
Review exact values, including case and emptiness. Mapping Pro does not explain what professional means. Replacing all values is broader than filling empty values; inspect the affected population before choosing it.
When adding a stored field, Fill existing empty records supplies an explicit constant. The creation-time policy remains separate. A default or AI autofill governs future new records that omit the field; it does not automatically backfill old records or rerun on updates.
Read the checks and business comparisons
A review shows proposed definitions, invalid values, affected saved items, pending work and the availability implications. Open details for each reported consumer. The checks can compare audience membership, workflow branches, message output or evaluated values when that comparison is available.
For an audience, inspect added and removed examples as well as before/after counts. If both counts are 250, the same 250 people may still not be selected. For a message, inspect the actual changed subject and body. For a workflow, inspect the branch and whether the check used current records or captured run input.
Read the stated coverage. Complete, sampled and unavailable evidence answer different questions. A sample does not establish every recipient's output. A check that cannot assess an item is unresolved evidence, rather than proof the item is unchanged. Current-record agreement also does not guarantee that every future valid value has the meaning your team intends.
Saved checks describe their captured input. If records, definitions or calculated publications change, the app can require fresh checks before saving. Use Refresh checks, Check again, or Prepare new review when offered, then read the new result. Do not treat a previous screenshot as the current review.
Resolve the reported blockers
| Reported issue | Next action |
|---|---|
| Values do not fit the new rules | Correct the conversion or source values and check again |
| A saved rule cannot accept the proposed value domain | Open the dependent item, prepare the intended replacement and review it with the change |
| A form still uses a removed field | Remove or repair that field reference through the review |
| Event producer input would break | Update the producer contract and complete the required source sample |
| Active work uses the old definition | Inspect the run or campaign and follow its reported waiting or stopping choice |
| An external result is unresolved | Reconcile that action before relying on the change |
| Review processing failed | Read the error; use Retry failed checks when the current review supports retry |
The dependency report identifies the specific item to inspect. A different display name does not repair a rule, and deleting a field does not make its remaining references safe. Avoid replacing an entire audience merely to bypass a blocker without checking the customer consequence.
Generation can prepare a replacement rule from your requirements. It uses AI credits where a generation action is requested. Review its explanation, affected inputs and resulting behavior; generation alone does not apply the proposal or establish correctness.
Test an event producer
A changed event contract can alter what a website or backend is allowed to submit. Check incoming events shows the source, environment, expected payload, test status and next action. A passing source sample is required when the review says so.
The sample must use the proposed fields and the appropriate source authentication. The review supplies a test command for your developer. Sample accepted establishes that one authenticated sample passed; it does not prove your deployed website, mobile app or queued server jobs all use that format.
Inspect both event properties and context. A collection binding takes properties from the event's attributes; its optional JSON Context attribute receives context and is excluded from producer properties. With no context attribute, the producer sends empty context. Native input must also satisfy the subject scope of a collection-bound event.
A producer sample cannot remove a blocker for an unsupported change to retained history. Existing occurrences cannot be backfilled with a newly required field. Keep that field optional, or create a new event type when the new contract requires it. Accepted occurrences remain historical facts. Coordinate the producer rollout and workflow meaning with the source owner, and account for retrying refused events during an application pause. See Events.
Account for active workflows
A workflow that is already running can hold captured input, published calculations or remaining actions that depend on the current setup. The review identifies that work. Inspect View run to distinguish a waiting customer journey from an action whose external result is unresolved.
Where offered, a waiting plan retains new entries in the selected workflows while existing work finishes. It does not stop all record writes. Retained entries are checked against the current workflow after application or cancellation; retaining an entry is not proof it eventually starts a run.
The review shows active runs, pending accepted entries, continuations and unresolved effects. A known wake time is an observation, not a promise that the run completes then. A manually paused workflow or stopped trigger remains stopped after the change.
Let a blocking run finish when its remaining work is still wanted. Terminate run stops that run, its child runs and remaining email follow-ups. Those do not resume later. Already accepted emails or external actions cannot be undone. Pausing the workflow does not finish its existing work or resolve an uncertain external result.
Apply and follow space availability
When checks require a decision, use the action the review offers. Save change applies a reviewed change; Pause space and save starts the final switch for a prepared change. A paused fresh review can require Apply and reopen space after you inspect its checks.
| Status | What it means |
|---|---|
| Draft | The proposal still needs its review |
| Ready to save | A reviewed proposal exists; inspect blockers and application controls |
| Preparing data | Proposed values are being prepared; the current setup can remain live |
| Preparing to apply | Accepted work is finishing before the change switches |
| Applying changes | Publication and service checks are in progress |
| Needs a new review | Resolve the reported problem and prepare current checks |
| Applied | Definitions committed; also inspect availability and resumption |
| Cancelled | The proposal was cancelled; inspect any remaining reopening or release work |
Read the availability panel beside these statuses. Some changes preserve normal traffic during preparation, then pause the space for the final switch. During draining or a pause, new record, event or send requests can be refused and need a retry. Refused requests are not saved for later. Accepted work and retained workflow entries follow their own completion rules.
Publication makes the prepared values and saved rules current together. Once that switch commits, recovery must finish; cancellation is not a rollback of the committed setup or of actions already accepted. Inspect the offered action and current state before trying to stop an application.
No fixed pause duration is promised. The review can show a review-window deadline, but reopening and recovery can take longer. Keep the change page available to the person coordinating producer retries and customer automation.
Recover an uncertain save or application
While Waiting to save is shown, the save has not started and the app retries admission. Keep the page open. Once a change exists, inspect that existing change instead of repeatedly submitting copies.
After an uncertain application response, choose Check Apply status when offered. This checks whether application started; it does not apply again. Read the returned state, blockers and availability before choosing the next action.
Cancel change abandons an unapplied proposal. Cancel and reopen space requests release of a paused change. Cancellation can still require reopening and hold release. Do not assume normal producer traffic resumed because you clicked the cancel control.
If source data changed, refresh the review. If a current check failed transiently, retry its checks. If the intended business meaning changed, edit the proposal and prepare a new review. These actions solve different problems; a retry should not silently change your conversion policy.
Inspect the completed result
The completion panel distinguishes Applied. Space available., Applied. Space is not available yet., and Applied. Some work is waiting to resume. Inspect updated-record counts and workflow checks, then open View automation status.
Check event intake, workflow holds, unresolved external action results and observed runs. No runs observed yet does not establish that workflow execution succeeded. The displayed run counts cover observed activity and may be bounded; they do not guarantee future runs.
Reopen representative records and inspect the actual field values. Test an inclusion, an exclusion and a missing value in the affected audience. For a scheduled evaluated field, check Data through and publication readiness separately. A committed definition is not the same as a completed fresh evaluation or delivered campaign.
Related
- Attributes: field settings and conversion controls.
- Events: native occurrences, collection bindings and producer identity.
- Attribute expansion: on-demand reads and captured publications.
- Segments: inspect audience meaning and shared dependencies.
- Workflow runs: diagnose remaining customer actions.