AFM is set up as a job in the Scheduler Manager of the source Fylr. Create a job, pick [AFM] Attention Fylr Mirror as its scheduler action and click Configure. One job mirrors one object type to one destination; create several jobs to mirror several object types or to feed several destinations.

Schedule the job like any other with its cron expression. A nightly run is the usual choice; shorter intervals work as well, since unchanged files and an unchanged data model are not transferred again.

AFM starts at Source Object Type and follows every link field and every nested table to the object types they point to, then continues from there until no new object type is found. All object types found this way are created on the destination, or updated when they exist already, with:

• their settings: pool managed, hierarchical, visible in the main search, permissions and tags enabled,
• their names in every database language,
• their fields, with mandatory, default value, unique, validation and length settings and their names,
• their masks, including the mask settings and which mask is the preferred one.

These field types are mirrored: text (single and multi line, also multilingual), number, decimal number, currency, yes/no, date, date and time, date range, geographic location, file, link to object, nested table, as well as the GND and Web Link custom data types. Fields of other types are not created on the destination and their values are not copied.

AFM only adds and updates. Object types, fields and masks that exist on the destination but not on the source are left alone, so the destination may carry additional object types of its own. The data model of the destination is only saved and released when something actually changed, because every release makes Fylr re-index.

• Pools: every pool that holds a mirrored item is created on the destination, together with all of its parent pools, with its names and permissions.
• Tags: every tag group and tag assigned to at least one mirrored item is created on the destination, with its names, descriptions, icon, color and its settings for enabled, default and persistent. Tags nobody uses on the source are not copied.
• Permissions of the mirrored object types and pools are replaced by the permissions of the source on every run. Entries can only be carried over for groups and users that exist on the destination as mirrored twins, so without Mirror Groups the mirrored object types and pools end up without any permission entries on the destination. System groups such as All users are not copied but assigned to the destination's own system group of the same kind.

With Mirror Groups enabled, all groups of the source are copied with their settings. With Mirror Users enabled as well, all users that are managed in Fylr itself are copied with their password, their personal settings and their group memberships. Users and groups whose names already exist on the destination are taken over and updated instead of being created a second time.

Language settings a destination does not offer are removed from the copied users.

Each item keeps its identity on the destination: the copy is created with the same unique ID (UUID) as the source item, and every later run updates that copy instead of creating a new one. Of every item AFM mirrors:

• the pool it belongs to,
• every editable field value; multilingual values for the languages both installations have,
• links to other items, which are resolved to the copies of the linked items on the destination,
• nested tables, which are rebuilt from the source on every run,
• the tags of its tag groups,
• the files of its file fields. A file is transferred only when the field on the destination does not already hold a file with identical content; which file is the preferred one is kept in line as well.

Hierarchical object types are mirrored parents first, so every copied item finds its parent on the destination.

When an item is deleted on the source, its copy on the destination is deleted on the next run. When a source item reappears whose copy had been deleted on the destination, the copy is restored rather than created anew.

An item that stops matching Query is no longer updated, but its copy stays on the destination. To withdraw such items, enter a Delete Items Query that matches them. A typical pair is:

Keep the two queries mutually exclusive. An item matching both is copied and deleted again on every run.

• Do not edit mirrored content on the destination. Every run brings the destination back in line with the source; changes made on the destination to mirrored items, fields, masks, pools, tags or permissions are overwritten. Files added to a mirrored item on the destination are kept, but files removed from an item on the source are not removed on the destination either.
• Keep the AFM markers. AFM recognises the pools, tags, tag groups, groups and users it created by a marker in their Comment (pools) or Reference field (all others). Changing or clearing that field makes the next run create a second copy.
• Run one job per destination at a time. Two scheduler services running the same mirror job simultaneously compete for the same objects and fail. When more than one scheduler service is connected, assign the job to a named instance - see Instances.
• Errors on single items do not stop the run. An item that cannot be copied is reported in the scheduler log and retried on the next run. Errors in the data model, masks, pools, tags, users or groups stop the run before any item is copied, so the destination is never filled with items it cannot hold.
• The first run takes longest. It creates the data model and transfers every file. Later runs only transfer what changed, plus the nested tables, which are always rebuilt.