Where mapping fits in the flow
By the time you reach Map data to transform (step 4), you have already:
Selected the data source project.
Applied eligibility criteria so only the right records are included.
Configured groups (if the integration supports them).
Mapping is the step where Aragorn AI turns your cleaned project data into the outbound shape—field names and formats the vendor or workflow requires.
Why map twice?
You already mapped HRIS columns to standardized fields in your data project. Integration mapping is a second step with a different purpose:
Layer | What it does |
Project (source) mapping | Normalize HRIS columns into one consistent schema inside Aragorn AI |
Integration mapping | Reshape that schema for each vendor or workflow |
Example: Your project stores first_name. Carta expects firstName.
ADP may expect a different label again. One clean employee project can feed payroll, benefits, equity, and identity integrations—you only change the outbound mapping per integration.
Without project standardization, you would maintain separate data projects (and cleanup) for every vendor. With it, integrations read from one source of truth and you adjust the shape at send time.
Open integration mapping
Log in to your Aragorn AI account.
Open Integrations and select your integration.
Go to the Map data to transform step.
The left side shows vendor fields (or workflow fields). The right side lets you assign project standardized fields as the source of each value.
Required vendor fields
Vendors define fields they require. If required fields are not mapped, the integration attempt may be invalid or fail validation before data is sent.
For each required vendor field:
Find the matching project standardized field (for example, project
first_name→ vendorfirstName).Save the mapping.
Required fields are always visible—you must map them to proceed.
Optional vendor fields
Some vendor fields are optional. They often appear grayed out until you enable them. Whether to send optional data is an organizational choice:
Minimal sharing — Map and send only what the vendor strictly requires.
Fuller profile — Enable optional fields (for example,
middle_name,work_email,personal_email) and map them when your project has the data.
To include an optional field:
Enable the vendor field.
Map it to a project standardized field.
If the project does not contain that data, you cannot send it until the field exists in the project (via source mapping, enrichment, or calculated fields).
Many-to-one mapping
Mapping is not always one project field to one vendor field. Multiple vendor fields can pull from the same project field.
Example: Carta has separate home_address and tax_address fields. Your project has one tax_address field.
You can map tax_address to both vendor fields when the values should be the same—or map tax_address only to tax_address if Carta provides a dedicated tax field and the addresses differ.
Each vendor field asks: where should I get my value? The same project field can answer that question for more than one outbound field.
Nullable vs required
Some mapped fields support a nullable toggle:
Setting | Behavior |
Nullable | You may send the field, but blank values are allowed (for example, optional |
Required | Every record must have a value before Aragorn AI sends data—even if the vendor would accept blanks. |
If you mark a field required and any employee lacks a value, Aragorn AI fails the job during validation with an error such as middle name is missing—before contacting the vendor.
Mapping tips
Map required fields first, then optional fields your organization allows.
Confirm the project final dataset actually contains the values you map—especially for optional or enriched fields.
After changing mapping, run an integration integrity check on the project if integrations report missing required data.
After changing mapping
Run the integration in test mode to verify output without delivering to the vendor.
Inspect the generated report or payload in job history.