Clone — pulling down

Clone refreshes this instance from its superior. It only ever pulls down, never the other way, so a development site can be brought close to production without production ever being at risk from it.

What comes by default

Two buckets, with deliberately opposite defaults:

• PFM configuration — everything that describes how your system is built: the entity and field definitions, all the administration (roles, groups and their members, applications and modules, forms, dialogs, actions, business rules, UI policies, visibility and view rules, numbering, REST messages and routes), the configuration records and the workflows. Cloned by default, because a development instance that does not match production's shape is not a development instance.
• PFM data — your business records: tickets, contacts, projects, orders. Not cloned by default, because production data has no business being copied onto a laptop just because somebody clicked a button.

With no rules at all, those defaults are the whole plan, and the plan page says so. And the staging configuration itself is skipped always: a Clone must never overwrite the very connection and plan that drive it.

The rules that change it

The plan holds two lists, and each one bends its bucket's default:

• Exclude configuration — names what should not come down: an entity (its definition and its configuration records), a family of the administration by its name — role, group, group_role, group_user, application, module, form_layout, dialog, action, ui_policy, business_rule, row_visibility_rule, view_rule, number_sequence, rest_message, scripted_route — or workflows.
• Include data — names an entity whose records should come down, narrowed by an EQL expression. An empty expression means all of its rows; status=open means only those. This is how you bring down the fifty tickets you need to reproduce a problem instead of the two hundred thousand you do not.

Running it, now or later

Run now executes the saved plan immediately. The Schedule box arms exactly one run at a date and time in the site's own timezone: the date is consumed when it fires, so scheduling again is an explicit act, and clearing the date cancels a pending run. There is no recurring clone by design — a copy that lands on top of your work every night, unasked, is a trap rather than a feature.

What the run tells you

A run lands things in the order they depend on each other: the entity definitions first, then each family of the administration, then the records, then the workflows — which arrive as exact copies, with their status and dates. Two kinds of workflow are left to the destination: a business rule's companion (the rule that came down recomposes it) and a seeded package's own, such as ITSM or Agile.

Every step leaves a line in Clone runs: done, skipped with the reason, or failed with the reason — and a row that could not land says which one and why, for instance a module whose application is not there, or a workflow that uses a table this instance does not have. The run header carries the totals, and a run that could only do part of its work ends as Partial, not as a green tick.

This is the contract: no silent truncation. If something did not come down, the run says which thing and why, and you can read it afterwards instead of discovering the gap weeks later.