Change sets

Every configuration change made through the MCP server is a change set: a proposal with a diff that you review before anything happens.

Lifecycle

1. Propose. The app sends the items to create or change, the items to delete, and workflow version actions. The server validates them and computes the diff. Nothing is saved to the configuration yet.
2. Review. The app shows you the diff: what is added, changed and deleted, field by field. Lines starting with effect: say what applying rebuilds (file format parsing trees, phrase indexes, inbox routing).
3. Test. The testers test_rule, test_workflow_step, test_file_format and test_capture_rules accept the change set id, so the app can show how the proposed configuration behaves on real invoices before you approve.
4. Apply. After you approve, the change set is applied exactly as proposed: all or nothing, with one Change History entry.
5. Revert. An applied change set can be reverted. The revert is a new change set with the inverse diff, which you review and approve the same way.

If someone changed the same configuration after the proposal, applying is refused and the app proposes again on the current configuration. Read the new diff.

Ways to build a change set

Tool	Use it to
propose_changes	Change a few fields (patches: set, unset or append by path), rework whole items, delete items, publish a workflow version or start or end a workflow test.
copy_config	Copy sections or items from another customer in the same environment. You need AI access to both.
validate_import	Turn a configuration export file (for example from another environment) into a change set.
initialise_from_template	Copy the template tenant's configuration, all sections or chosen ones. It does not clear the customer first; clear and reinitialise stays in the portal.
revert_changeset	Undo an applied change set.

Items and ids

Configuration items are read and written in the export shape: the same JSON as the portal's configuration export. get_config_item returns it, propose_changes accepts it. Each item has a config_item_id that is stable across environments, so an item keeps its id when it is exported from one environment and imported into another.

Before deleting an item, the app runs find_references to see what depends on it.

Changes outside the configuration

Users, user groups, API users, webhooks, supplier integration access, CDN files, maintenance windows and Excel imports are not configuration items. Their manage_* tools work in two steps:

1. Without confirm, the tool describes what would happen, including emails that would be sent and data or access that would leave Nuntiq.
2. With confirm: true, after you agreed, it does it.

These changes are also in the Change History under your name with the app.