Sync — pushing up
Sync carries what you built here up to the superior. It never pulls, and it never pushes on its own: you compute the difference, read it, select what should travel, and push that.
Compute first, then choose
Compute diff asks both instances what they have and stores the result as records you can filter, sort and save views on, like any other list in the platform. The list is the stored result of the last computation — the Computed column says when — so nothing moves against a picture you have not seen.
Then you select rows and press Push selected. Only what you ticked travels.
What is compared, and what can travel
| Lane | Compared how | Can it be pushed? |
|---|---|---|
| Schema definitions | Entity and field definitions, property by property | Yes — and always applied on the superior before any workflow, so the shape exists before anything depends on it |
| Configuration records | Presence on each side, by the identity the record carries across instances | Yes |
| Workflows | By content: the name and the canonicalised graph, with positions on the canvas ignored | Yes |
| Table configuration — business rules, actions, UI policies, REST messages, scripted REST, OAuth clients and connections | Content, key by key, with both values shown | Not yet. The comparison is real and readable; the apply lane for these families is being built, and the push refuses them by name rather than pretending |
Two kinds of workflow never travel, by construction: the companion workflow a business rule creates for itself (it is recomposed by the destination from the rule) and workflows owned by a seeded package such as ITSM or Agile (the destination's own installer owns them). Pushing those would create duplicates that nobody asked for.
Rows you will see, and what they mean
- New here — exists on this instance, not on the superior. Pushable.
- Differs — exists on both, and the content is not the same. Pushable.
- New on the superior — exists only above. Informational: Sync pushes up, so this is something to notice, not something to act on here.
- Conflict — the same workflow identity is carried by more than one workflow on one of the two sides. Never guessed: the row says so and the push refuses it until you resolve it yourself.
What never travels
Secrets are not in the comparison and are not on the wire — not a password, not a token, not a credential. Neither are the identifiers an instance mints for itself, nor operational noise such as timestamps and last-error messages. What is matched is the real identity of the thing: the entity and name of a rule, a message key, a workflow's own uid.
The consequence is worth stating plainly: pushing a configuration up never carries the superior's credentials away, and never replaces them with the lower instance's own.