Note: This article has structural updates only.
Imports are powerful because they can create or update large volumes of records quickly. They are also one of the easiest ways to accidentally fork data if matching logic and scope are not understood.
This article defines the conceptual rules that keep imports safe and predictable.
Contents
- Core Principles
- Matching: Create vs Update
- History Preservation
- Operational Governance for Power Users
- Where to Go Next
For an overview of how core records relate across Accounts, Contacts, Companies, and other entities, see: Course Management.
Core Principles
- Imports are deterministic: outcomes depend on matching rules and identifiers.
- Good imports rely on stable IDs and consistent ownership boundaries.
- Bad imports create duplicates that “look valid” and silently degrade reporting.
Matching: Create vs Update
The import engine must decide whether each row represents a new record or an update to an existing record. This decision is driven by matching precedence and identifiers.
Power-user expectation: you should be able to explain why a row created a new record before you run a production import.
History Preservation
Administrate prefers preserving historical participation truth. Imports should not be treated as a tool to retroactively rewrite past participation records without a deliberate strategy.
Operational Governance for Power Users
- Validate identifiers and matching columns before running large imports.
- Test in a controlled scope before broad production runs.
- When in doubt, design the import to prevent accidental record creation.
Where to Go Next
- Reporting: How Data Rolls Up (and Why It Sometimes Doesn’t)
- Accounts, Contacts, Learners & Roles: Identity and Participation
Procedural reference: