Attention Fylr Mirror (AFM) replicates content from one Fylr installation to another and keeps the copy up to date. It copies an object type from a source Fylr to a destination Fylr, together with everything that object type needs to work on the other side: the data model, masks, pools, tags, permissions, optionally users and groups, and of course the items and their files.

AFM plugs into the standard Attention Scheduler and runs on whatever interval you choose. Every run is unattended and can be repeated as often as you like: AFM recognises what it copied before, updates it in place and only adds what is missing, so running it nightly costs little more than the changes made since the previous night.

• One-way and predictable. The source is always the authoritative side. The destination is brought into line with it on every run, never the other way round, so there is no conflict handling to configure and nothing to merge.
• Complete, not just metadata. An item is only useful on the destination if its object type, its fields, its pool, its tags and the items it links to exist there as well. AFM follows the links of the chosen object type and brings all of it across in the right order.
• Selective. A search query decides which items of the chosen object type are mirrored, so the destination can carry a curated subset - for example only approved or public material - instead of the whole database.
• Safe to re-run. Items keep their identity across both installations. A second run never duplicates an item, a pool or a tag; it updates the copy made by the first run. Files are only transferred when the destination does not hold the same file yet.
• No manual exports. No export files, no import mapping, no hand-made data model on the destination. Point AFM at an empty Fylr and the first run builds everything it needs.

• Public or partner portal. Run an internal Fylr for the editorial work and a separate Fylr for publication. AFM copies the released items to the publication instance, so the internal system is never exposed to the outside.
• Staging and production. Keep a test installation filled with current production content to try out data model changes, AWP portals or plugins on realistic data.
• Distributed sites. Provide a branch office, a subsidiary or a partner with its own Fylr carrying the part of the collection that concerns it.
• Migration to a new installation. Move an object type with its items and files from one Fylr to another, and keep the new installation current with repeated runs until the old one is switched off.

Starting from the chosen object type, AFM copies:

• the data model of that object type and of every object type it links to or contains as a nested table, including masks and field settings,
• the pools that hold mirrored items, including their parent pools and their permissions,
• the tag groups and tags assigned to mirrored items,
• the permissions of the mirrored object types,
• optionally the groups and the users of the source,
• the items of all those object types with their field values, links, nested tables, tags and files, as well as the deletion of items that were deleted on the source.

The details, and what is deliberately left out, are described on the Configuration page.

AFM requires a license which needs to be installed on the source Fylr with the License Manager. Without it the mirror job fails with Product not licensed.