Connect ERP and HRMS workflows to AI without heavy customisation

Define authority at field level before connecting systems

Assign one authoritative source for each shared field. In a particular organisation, HRMS might own employee status and department while ERP owns supplier details and purchase-order status. These are choices to document, not universal product rules. State which system may propose a change and which owner authorises it.

List the decision the workflow supports and remove fields it does not need. An onboarding checklist may require employee ID, start date and department without salary or identity documents. Give the integration account the minimum read scope and test with a role that represents the intended operator. A broad administrator connection can make an otherwise narrow pilot too exposed.

Check supported interfaces and stable record identifiers

Inspect the installed system version, licensed integration features and documented interface before choosing a platform. A regular export can be sufficient when a daily report meets the task. Prefer a supported connector or API over editing core screens or database tables; compare the maintenance and upgrade implications before commissioning custom work.

Build a mapping between source-system ID and destination-system ID. Names, email addresses and row positions can change or collide. SCIM’s core schema defines stable, non-reassignable resource IDs for systems implementing that standard. Dataverse documents alternate keys for identifying rows with external business identifiers. These illustrate useful mechanisms; verify what your actual ERP and HRMS support.

Separate data synchronisation from AI interpretation

Copy authorised fields through explicit mappings: what counts as active, which time zone a timestamp uses and how department codes correspond. Version the mapping and reject unknown codes. AI should not decide that two similar names are the same employee or rewrite a source status because the wording sounds more convenient.

Place AI above that controlled view to draft an explanation, identify an apparent inconsistency or summarise a request. Show record IDs, source timestamps and supporting fields alongside its output. Mark suggestions as suggestions. A generated answer about a purchase order must not become the order’s recorded approval status.

Worked example: a read-only onboarding handover

Hypothetical example, not a client project: HRMS holds a new colleague’s confirmed start date and department, while ERP holds an equipment request keyed to employee ID. A read-only view joins those IDs and shows that the equipment request is still open. AI drafts “Equipment request remains open; confirm readiness before the start date” with links to both records.

If no matching employee ID exists, send the record to a mapping queue; do not match by a similar name. If ERP data is older than the agreed freshness window, label the status as unverified and refresh or ask the owner. The pilot neither changes the start date nor approves a purchase. The receiving colleague confirms the next action in the existing system.

Design reconciliation and recovery before adding writes

An integration must handle more than new records. Include updates, inactive records, deletion rules, paging, repeated events and expired access. Microsoft Graph’s delta documentation describes removals, replays and synchronization resets for supported resources. Do not assume your ERP provides the same mechanism; document its actual change and recovery behaviour.

Record the last completed checkpoint and source version. Compare the read-only view with a fresh source sample after an interruption. If partial reads or an expired change token leave completeness uncertain, rebuild the bounded view using the supported procedure and reconcile before resuming. A later write pilot also needs duplicate-safe operations, destination checks and a field-level reversal plan.

• System owner and support contact for each connection.
• Authoritative fields, ID mapping and code definitions.
• Allowed access, excluded data and freshness window.
• Checkpoint, reconciliation method and exception owner.
• Pause control, manual handover and recovery procedure.

Judge the read-only pilot by usable, current handovers

Measure the current effort required to assemble the same handover. Mapping coverage = eligible source records with verified ID mappings divided by eligible source records. Freshness pass rate = checked records within the agreed age limit divided by records checked. Record material disagreements against the source, review time and unresolved exceptions separately from AI response speed.

Stop expansion when ownership conflicts persist, IDs cannot be verified, required access is too broad, freshness cannot meet the task or recovery produces unexplained differences. Compare configuration, export-based work and a small API adapter before proposing deep customisation. Keep any cost estimate in USD tied to scope, licences and maintenance, and approve writes as a separate stage.