A macro is a saved reply you can drop into a ticket: a title, a body written in Markdown, and a comma-separated list of tags. The macros screen lets you export the whole set to a file and paste a set back in, which is how most teams move templates between a sandbox and a live account, or seed a second brand from a first.
The export and the import are not symmetrical. Knowing exactly where they differ is the difference between a clean migration and a library full of duplicates attributed to the wrong person.
Who can see a macro
Every macro carries an author and a shared flag, and those two fields together decide visibility. When the screen lists macros for you it asks for rows where the macro is shared, or where you are the author. There is no third state and no per-team or per-department scoping: a macro is either yours alone or it is visible to everyone on the account.
That has a consequence worth internalising before you import anything. The list you can see is not the list that exists. Another agent's private macros are invisible to you, and they stay invisible no matter what you search for.
Results come back ordered by use count first and title second, so the templates your team actually reaches for float to the top on their own. Nobody has to curate that ordering, and it is a better signal of what belongs in the library than anyone's opinion.
What the export writes
Exporting downloads a JSON file named for the moment you asked for it, with a wrapper carrying the export timestamp, the site id and a count, and then one object per macro. Each macro object carries eight fields: the id, the title, the body, the tags, the shared flag, the author's agent id, the use count and the creation timestamp.
Per macro that is a complete record, and it includes the usage data that tells you which templates are load-bearing and which have never been touched. But the export reads the same single page of results the list does, so it carries at most two hundred macros, and it carries the shared macros plus your own rather than everyone's. Two people exporting the same account do not necessarily produce the same file. Check the count field against what you expect before you treat the download as a backup.
What the import reads, and what it drops
The importer accepts the same shape the exporter produces, and it reads exactly four fields from each object: title, body, tags and the shared flag. The other four are ignored.
So a full round trip through export and import is lossy in a specific and predictable way:
- The id is not preserved. Imported macros are new rows with new ids. Nothing that referenced the old id still points at anything.
- Authorship moves to you. The importer stamps the importing agent as the author of every row it creates. Import a colleague's export and the whole library becomes yours.
- Use counts reset to zero. The usage history that produced the useful default ordering does not come across, so a freshly imported library is ordered by title alone until the team starts using it again.
- Creation dates reset. The new rows are created now, not when the originals were.
None of this is a problem if you know it. It is a problem if you assume a round trip is a copy, migrate a mature library, and then wonder why the ordering that used to put the right template first no longer does.
Where the duplicate check stops looking
The importer will not create a macro whose title already exists. It builds a set of the titles you can currently see, compares each incoming title against it case-insensitively after trimming whitespace, and skips the matches. It also adds each title it creates to that set as it goes, so a file containing the same title twice yields one macro rather than two.
Two limits on that check matter in practice.
The first is size. The set is built from a single page of your macros, and that page holds at most two hundred rows. If your account has more macros than that, the ones past the boundary are not in the comparison set, and an incoming macro matching one of them will be created rather than skipped.
The second is visibility, and it follows from the rule above. The set contains only the macros you can see. If another agent has a private macro titled the same as one in your file, the importer cannot see it, does not consider it a match, and creates a second macro with the same title. The account now has two, owned by different people, and only an admin looking at both accounts would spot it.
The import reports three counts when it finishes: created, skipped and failed. Skipped covers both duplicates and rows missing a title or a body, which the importer treats as incomplete rather than as an error. Failed covers rows that threw while being written. A run that reports a large skipped count is usually telling you the file has already been imported, not that something went wrong.
Sharing on purpose rather than by accident
The shared flag travels with the import, which is the one field where the round trip's fidelity works against you. If you exported a set that included your own private drafts, those drafts arrive at the destination with their flag intact. That is correct behaviour, and it is also how half-finished templates end up in a shared library.
Before you export a set intended for someone else, filter it. It is easier to delete three rows from a JSON file than to explain to a colleague why the macro they just sent a customer ended with a note to yourself.
The same reasoning applies in reverse. A macro that everyone should use is worth marking shared explicitly rather than leaving private and pasting into chat when someone asks. A shared knowledge base and a shared macro library solve different halves of the same problem: the first is what the customer can find, the second is what your agents send.
Doing the migration cleanly
A sequence that avoids every trap above:
- Export from the source account and keep the file. It is your backup and your audit trail, and it carries the use counts the destination will not.
- Open the file and delete anything private, half-written or specific to the old account. This is the only point where filtering is cheap.
- Check the destination account's macro count. If it is near or past two hundred, import in themed batches and check for duplicate titles yourself afterwards, because the automatic check cannot cover the whole set.
- Import, then read the three counts. A skipped count you did not expect means the titles already existed.
- Fix authorship expectations out loud. Everything you just imported is attributed to you, so tell the team the library is shared regardless of whose name is on it.
Then leave the ordering alone for a few weeks. Use counts rebuild quickly once agents start working, and the library sorts itself into the shape your team actually needs rather than the shape the old account had.