Every advancement team has someone who “knows how to do the imports.” They know which columns go where, which fields are required, what format the dates need to be in, and which lookups will fail if you spell “Organization” as “Org.”
That person is invaluable — until they’re on vacation the week the giving day file needs to land.
Import Studio templates solve this by encoding all of that institutional knowledge into a reusable, shareable configuration. Once a template is built, anyone on the team can run the import and get the same result. The template enforces the rules; the person running it just needs to supply the data.
An Import Studio template defines four things:
Template: “Annual Fund Gifts”
1. Target — Which record type are we writing to? → Gifts & Contributions
2. Field Mappings — Which columns in your file map to which fields in CRM?
- “Gift Amount” → Amount (required, must be a number)
- “Donor ID” → Constituent (required, must match an existing person)
- “Gift Date” → Date (required, format: MM/DD/YYYY)
- “Designation” → Fund Designation (required, must match a valid fund)
- “Notes” → Gift Notes (optional, max 2,000 characters)
3. Rules — What checks and cleanup should happen automatically?
- Trim whitespace from all text fields
- Normalize phone numbers to (XXX) XXX-XXXX
- Require at least one of: Email or Phone
4. Duplicate Detection — How do we avoid double-counting?
- Match on: Donor ID + Gift Date + Amount
- If a match is found: skip the row (it’s already recorded)
Let’s dig into each layer.
Every field in a template has these properties:
| Property | What it controls | Example |
|---|---|---|
| Display Name | What the user sees in the UI | ”First Name” |
| Schema Name | What CRM calls the field | firstname |
| Data Type | How to interpret the value | text, date, number, lookup |
| Requirement | Must it have a value? | Required, Optional, or Ignore |
| Default | What to use if the cell is empty | ”Unknown” or today’s date |
| Format | Expected input format | MM/dd/yyyy for dates |
This means your file doesn’t need to use CRM’s internal schema names as column headers. The template maps “Gift Amount” to elcn_amount automatically. Users work in plain language; the system handles the translation.
Each field can carry validation rules written in a simple, readable syntax. Here’s an example for an email address field:
Field: “Email Address”
Rules: must be filled in, must be a valid email, must be 255 characters or fewer
jsmith@university.edu→ passes all three rulesjsmith@→ fails — not a valid email- (left blank) → fails — field is required
- (256 characters) → fails — exceeds maximum length
Validation happens before anything is written, so you’ll see these issues in the pre-flight check — not as mysterious failures after the import runs.
| Rule | What it checks |
|---|---|
required | Field cannot be blank |
email | Must be a valid email format |
numeric | Must be a number |
date | Must be a parseable date |
max:N | String length cannot exceed N characters |
min:N | Numeric value must be at least N |
unique | Value must be unique across all rows in the file |
Rules are composable — you chain them with | to build exactly the validation your data needs.
Sometimes no single field is required, but one of a group must be present. For example: every contact needs either an email address or a phone number, but not necessarily both.
Conditional Requirement
A row is valid if it has data in at least one of these fields:
- Email Address
- Phone Number
So a contact with just a phone number? Valid. Just an email? Also valid. Neither one? That row gets flagged.
This eliminates the “required field” problem where you’d have to mark everything as optional (too permissive) or required (too restrictive) — you can express the actual business rule.
Validation tells you what’s wrong. Transformations fix what’s fixable — automatically, before the row hits CRM.
| Transform | What it does | Before → After |
|---|---|---|
trim | Remove leading/trailing spaces | ” John ” → “John” |
uppercase | Convert to uppercase | ”smith” → “SMITH” |
lowercase | Convert to lowercase | ”SMITH” → “smith” |
replace:old,new | Substitute text | ”N/A” → "" (empty) |
phone | Normalize phone format | ”6175551234” → “(617) 555-1234” |
address | Standardize address | ”123 main st.” → “123 Main St” |
name | Parse name components | ”Dr. Jane Smith Jr.” → First: Jane, Last: Smith |
Transforms run before validation. This is important because it means:
So your validation rules can be strict without rejecting data that’s just formatted differently.
Example: How a phone number gets cleaned up
Your file contains:
617.555.1234
- Trim → removes extra spaces →
617.555.1234- Phone normalize → reformats →
(617) 555-1234- Validate → checks the result → valid phone number ✔️
- Duplicate check → is this number already on file?
- Write to CRM → saved in the correct format
The person uploading the file doesn’t need to worry about formatting. The template handles it.
Real-world imports rarely touch a single table. When you import a contact, you usually also need to create or update their phone number, email, mailing address, or organizational affiliation — all of which are separate entities in CRM.
Import Studio templates support linked entities: additional CRM records that get created or updated alongside the primary record.
Template: “New Constituents”
Primary record: Contact
- First Name (required)
- Last Name (required)
- External ID (required — used for matching)
Also creates: Phone record
- Phone Number (required if any phone info is provided)
- Phone Type (defaults to “Mobile” if not specified)
- Skipped entirely if the phone columns are blank
Also creates: Email record
- Email Address (required if any email info is provided)
- Email Type (defaults to “Personal” if not specified)
- Skipped entirely if the email columns are blank
Also creates: Mailing Address
- Street, City, State, Zip
- Skipped entirely if all address columns are blank
The “skip if empty” behavior is key: if a row in your file doesn’t have a phone number, Import Studio won’t try to create a blank phone record. It just skips that piece for that row.
For scenarios that go beyond field mapping and validation, Import Studio supports custom actions — small scripts that execute at specific points during the import:
| Trigger | When it runs | Use case |
|---|---|---|
| Document Setup | Once, before any rows process | Initialize caches, set global defaults |
| Row Setup | Before each row is written | Look up related records, calculate values |
| Row Teardown | After each row is written | Trigger follow-up actions, log results |
| Document Teardown | Once, after all rows process | Send summary notifications, finalize |
When importing employment records, the employer organization might not be flagged as a “constituent” in CRM yet. A custom action can:
This kind of logic would be impossible in a flat field-mapping tool. Import Studio lets you embed it directly in the template so it runs every time — no manual intervention needed.
Templates go through a lifecycle that prevents untested configurations from hitting production data:
Draft → Test → Published
Draft — You’re designing the template. Change anything freely. Nothing touches real data.
Test — Run the template against sample data with built-in test scenarios. The test engine verifies:
Published — The template is live and available to your whole team for real imports. Changes require creating a new version (so you never accidentally break a working template).
Here are common templates we’ve seen advancement teams create:
| Template | Primary Entity | Key features |
|---|---|---|
| Giving Day Gifts | Contribution | Duplicate detection on donor + amount + date; auto-lookup designation codes |
| Event Attendance | Activity (Appointment) | Linked attendee records; auto-set activity type and status |
| Vendor Phone Append | Phone | Normalize all formats; detect existing numbers; skip if already on file |
| Portfolio Reassignment | Prospect | Lifecycle management; end-date old assignments; create new ones |
| Annual Address Update | Address | USPS format standardization; mark old address as inactive |
| Rating/Score Import | Rating | Validate against allowed rating codes; prevent duplicate active ratings |
The point of templates isn’t to make every import identical. It’s to make the rules consistent while the data varies. Your team can:
That’s the difference between a data import process and a data import system.
Import Studio templates are currently built in DLight and are migrating to Corral Works, where they’ll gain:
This is part three of a three-part series on Import Studio:
Import Studio is included in Corral Works. If you’d like to see how templates could standardize your team’s import process, reach out for a demo.