Importing and Exporting Models

The file#

An exported model is a .flowMdl file. It is a structured description of the entities you selected — folders, metrics, measures, event schemes, charts, dashboards, and the supporting objects they depend on.

An export is a description, not a database backup. It carries configuration, not calculated values.

What travels and what does not#

An export carries 35 collections. This is the complete list, read from the export model at release/7.2.0:

Four points that are easy to get wrong:

No values. Importing a model gives you the structure, and the engine calculates forward from the point it is deployed. History is not transferred. If you need history, that is a database restore, not an import.

Connections arrive empty, not merely without a password. The exported connection carries only its name, type, template link and locks — no properties at all. Server, port, database, timeouts and credentials are all absent, because those settings are held against the connection rather than inside the exported object. Plan on configuring every imported connection from scratch and re-testing it, rather than filling in one password field.

Deployment objects do travel. Engines, integration engines, consumers, locations and template server registrations are all part of a model import, and the import runs those steps unconditionally. An import is therefore not a purely model-shaped operation — it can add engines to the destination. Review the deployment tree after importing into an instance that already has one, as described in The Deployment View.

Group names travel; people do not. The export carries each group's id and name and nothing else — no accounts, no membership. That is what lets folder permissions reattach at the destination, because restriction is decided by group assignment on a metric folder (see Object Operations in Flow Config). After importing, those groups exist but are empty, so every secured folder is closed to everyone except administrators until you populate them — see Users, Groups and Access.

Scope: export what you need, not everything#

You can export at several scopes — the whole model, a folder subtree, a set of charts, a dashboard.

Narrow scope is usually better. It transfers faster, is easier to review, and produces far fewer mapping decisions on import.

Dependencies come along#

An export includes what the selected entities need in order to make sense. Export a calculated measure and the measures it depends on are included; export a chart and the measures it displays come too.

This is helpful and occasionally surprising: a narrowly scoped export can pull in a great deal more than you selected, because something in it referenced a measure elsewhere in the tree. Review the contents of an export before relying on its size.

Importing and mapping#

Importing is not a blind copy. The destination already has its own entities, its own IDs, and possibly its own version of the thing you are importing. Infohub resolves this by mapping.

Import operations fall into a few kinds:

Matching works by identity first, then by name within the containing entity. That has a practical implication worth knowing: names matter on import. Two entities with the same name in the same container are ambiguous, and ambiguity is where imports produce copies instead of updates.

Connections need attention on the way in#

Because credentials do not travel, and because the destination's connections are its own, the reliable sequence is:

1. Create the connections you need in the destination before importing, named exactly as they are in the source.
2. Import the model.
3. Confirm each measure resolved to the intended connection.
4. Complete credentials and test each connection.
5. Deploy.

Getting the connection names to match beforehand removes most of the mapping work.

Plugin versions matter#

Connections and consumers are plugins, and their properties are defined by the plugin. If the destination has older plugin assemblies than the source, properties the older plugin does not understand can be lost on the way in — silently.

This shows up as a connection that imported "successfully" but has an empty query or a missing property that the source definitely had.

Common uses#

Development to production. Build and test on a development instance, export the finished subtree, import to production, complete connections, deploy.

Reusing a pattern across sites. Export an area that works well, import at another site, adjust attributes and tags. For repeated ongoing reuse, template servers are a better answer than repeated file transfer, because they keep the link.

Distributing demonstration or training content. A self-contained model built against the simulator imports anywhere and needs no external systems.

Backing up a subtree before restructuring. An export before a large change gives you something concrete to compare against, and to restore from if the change goes badly.

Import or template server?#

Both share content between instances. They differ in what happens next.

An import is a one-time copy. After import, the destination content is independent. Improvements to the source do not reach it.

A template server keeps the link. Instances derived from a remote template know where they came from and can be updated when the template changes.

If content will only ever be transferred once, import is simpler. If it is a pattern that will be maintained centrally and rolled out repeatedly, a template server is what you want.

Scripting it#

Both operations are available from the CLI, which makes environment promotion repeatable:

"Flow Config.exe" --host <server> --database <db> --export-model --export-file model.flowMdl [scope options]
"Flow Config.exe" --host <server> --database <db> --import --file model.flowMdl

Scripting is worth it for anything done more than twice. It also gives you a reviewable record of exactly what was promoted, which a series of clicks does not.

After importing#

1. Check the tree looks the way you expected — no duplicated folders, no unexpected Copy entities.
2. Verify a sample of measures: correct connection, correct tag, correct interval, correct aggregation.
3. Check calculated measures compile and their dependencies resolved.
4. Check model attributes arrived and are set at the right levels.
5. Complete and test connections.
6. Deploy, then confirm values arrive.

Step 2 is the one people skip. An import that resolved a measure to the wrong connection will look entirely normal until someone notices the numbers describe a different machine.

See also#

• Templates: Concepts
• Template Servers and Federation
• Deploying Configuration
• Upgrading to Flow 7.2.0