An integration is an agreement about information as well as a technical connection. HR, IT and operations teams need a shared answer to four questions: which record is authoritative, who may change it, when should it move and what happens if the update fails?
Start with records and identifiers
Map the objects that matter to the process: people, roles, competencies, opportunities and assignments. Identify the authoritative source for each field rather than declaring one entire application the owner of everything. An employee's identity may come from the HRIS while a campaign supplies newly reported skills evidence.
Agree stable identifiers and how records are matched across systems. Names and email addresses can change. Unresolved identity matches should be reviewed before updates create duplicate people or attach evidence to the wrong record.
Make direction and timing explicit
Reading a record, refreshing a snapshot and writing an update are different capabilities. Show which fields move in which direction and how often. A chart based on a prepared snapshot should carry a date; it should not be described as continuously live merely because an integration exists.
Define what happens when both systems can change the same field. The resolution may depend on ownership, timestamp or review. Agree it before a conflict occurs, and preserve enough context to explain the chosen value.
Configure access around the client process
Connection permissions should reflect the data and actions needed for the agreed use case. Participant access, administrative SuperBot access and system-to-system authority have different purposes. Explain them separately to the client team.
Public integration guidance can describe the operating model and examples. The authenticated operational catalogue and client access remain controlled. A public description of an integration does not grant permission to read data or execute an action.
Test failure and reconciliation with the team
Include missing identifiers, unavailable systems, stale records and rejected writes in the acceptance scenarios. Confirm how failures become visible, who receives the handover and how a retry avoids duplication. Reconcile key records after recovery.
Customer Success and Business Analysis colleagues work with client teams to translate these decisions into a configured deployment. Agree current connector availability, authentication, field coverage and write behaviour for each named system rather than assuming all suppliers offer the same access.
Follow the record that matters to your team
An illustrative integration map; connection behaviour is agreed for each deployment.
HRIS → stable employee identifier → EVA profile
How to read it
The agreed identity source anchors the profile. A campaign response should not silently create a second employee.
The next useful action
Resolve unmatched identities before attaching new assessment evidence.
Compare all 3 cases
| Case | Known information | Next action |
|---|---|---|
| Employee identity | HRIS → stable employee identifier → EVA profile | Resolve unmatched identities before attaching new assessment evidence. |
| Skills evidence | Participant response → dated evidence → authorised analysis | Apply the client's visibility configuration and review process. |
| Assignment update | Authorised workflow → destination system → confirmation | Check the response and reconcile before marking the workflow complete. |
Illustrative example. These controls explain the method; they do not access client records or execute workforce actions.
Connect systems around clear ownership and a recoverable process.
Explore the relevant EVA capabilitiesSources & further reading
This guide explains EVA's approach and illustrative methods. Follow the current offering and methodology pages for scope and examples.