“Keep the candidate's details up to date” leaves several decisions unanswered. Which system owns each detail? Does a blank mean unknown or an instruction to clear it? What happens when a consultant has changed the destination record since the source was last read?
A field mapping worksheet puts those decisions beside the field they affect. Use it with your administrator and integration owner before treating a connection as ready for a particular workflow. The examples below are illustrative business labels, not a list of fields or operations supported by FluxHire or any other connector.
Agree the record and direction first
Start with one business operation, such as updating an agreed detail on an existing record. Identify the source system, destination system, record type and the event that should initiate the operation. Ask the integration owner to supply the actual record identifiers and the method used to match them.
Avoid “both ways” as a direction. Write one row for each permitted direction, with its own owner and conflict rule. Reading a field and changing it are separate permissions. Creating a record and updating an existing one need separate decisions too.
Connector documentation shows why the scope matters. JobAdder's enableHR integration page describes placements creating employee records, while its table marks other record types as not synced. That is the scope of that connector, not a description of every JobAdder integration.
Record the documentation and configuration that apply to your connection. Where the integration owner cannot confirm a field or operation, leave it unconfirmed rather than borrowing a similar connector's mapping.
Copy the field agreement
Begin with this header:
Workflow and purpose: [the business operation].
Source and destination: [systems, record types and permitted direction].
Matching rule: [documented identifiers and what happens without a match].
Mapping owner and version: [responsible person, version and date].
Permission and privacy review: [approved scope and evidence reference].
Then give each proposed field its own row. You can keep the rule and test tables together in the same sheet, linked by the mapping reference.
| Mapping reference | Business meaning | Source and owner | Destination and owner | Permission and transformation |
|---|---|---|---|---|
| [reference] | [what this value means, including units or status meaning] | [verified field identifier/type and person responsible] | [verified field identifier/type and person responsible] | [read/create/update permission; agreed conversion or no change] |
| Mapping reference | Blank and clearing rule | Conflict rule | Restricted information | Evidence needed before use |
|---|---|---|---|---|
| [same reference] | [unknown, empty and intentional removal handled separately] | [how a newer or different destination value is resolved] | [excluded content and permitted access] | [test reference, observed result and reviewer] |
The business meaning deserves as much attention as the identifier. A “status” may describe a person, an application or a placement. A date may refer to an agreed start or an actual start. Write the meaning in words before anyone agrees to transform the value.
For personal information, the OAIC's APP 10 guidance includes consistent recording formats among its practical examples. A mapping can help preserve that consistency, but an agreed column name does not make an incorrect source value accurate.
Work through blanks and conflicting edits
Consider a hypothetical mapping for a professional contact detail. The source value is empty, while the destination contains a value a consultant recently confirmed.
If the mapping merely says “copy source to destination”, it has not resolved whether that empty value should remove the confirmed detail. Write the intended rule instead: for this illustrative mapping, an absent source value makes no change; an intentional removal requires a distinct authorised operation. The integration owner must confirm whether the actual connection can implement that distinction.
Now suppose both systems contain different values. Do not decide that the most recent import is the most recent information. Ask which source the agency has agreed to trust for this field, what the timestamps mean and whether the destination changed after the operation was prepared. Record who resolves the conflict and what happens while it remains unresolved.
Apply the same discipline to conversions. For a list value, agree each allowed source-to-destination meaning and the treatment of an unmapped value. For a date, agree the date's meaning and any time zone conversion. Do not silently substitute a convenient default when the source cannot support it.
These are proposed rules to settle with the owner, not claims about a connector's behaviour. If a rule cannot be implemented, narrow the mapping or change the workflow before testing it.
Keep private information out of an unnecessary mapping
Ask why each field needs to move. For covered entities, APP 3 guidance addresses necessary collection and data minimisation, while APP 6 addresses permitted use and disclosure. Having a technical destination for information does not answer those purpose questions.
Give private notes their own review. Confirm who may read them, who may act on them and how the existing author-only restrictions and outbound privacy controls are preserved. A general permission to update a contact must not become an assumed permission to send a private note elsewhere.
Use references to approved test evidence rather than placing whole candidate files in the worksheet. Agree access to the sheet and how its test material will be handled afterwards. The OAIC's APP 11 guidance covers reasonable security measures and disposal of personal information no longer needed, subject to its exceptions.
Add a result that somebody can check
Test the agreed rules in an authorised environment before expanding the workflow. JobAdder's developer resources describe a sandbox for validating integrations before production. Confirm the test access and setup available for your connection with its owner.
| Mapping reference | Test input and condition | Expected result | Observed destination evidence | Decision |
|---|---|---|---|---|
| [reference] | [ordinary permitted update] | [agreed value and unchanged fields] | [permitted record/result reference] | [reviewer, outcome and date] |
| [reference] | [blank, conflict or unmapped value] | [agreed no-change, hold or rejection] | [what actually happened] | [open issue and owner, or accepted] |
Keep an accepted request separate from a confirmed destination change. For a linked JobAdder record in FluxHire, ask the integration owner to show the result in JobAdder and how that confirmation is reflected in the application record. A successful submission receipt is not enough evidence to close that test.
For the wider exercise, use the JobAdder integration pilot guide. This field sheet supplies the detailed agreement the pilot tests; the integration checklist covers the broader operational questions.
Connect the mapping to the review decision in FluxHire
FluxHire's AI agents prepare proposed changes to existing records for review and approval. During early access, record edits are made by people holding the records editor permission. The field agreement gives that reviewer something concrete to compare with the proposal: the value's meaning, the permitted destination and the rule for a conflict. The person still checks whether the proposed change is appropriate.
With FluxHire's JobAdder integration, field write-back is set up with your administrator during onboarding and controlled centrally. Bring the worksheet when you Request early access, so the supported records, directions, permissions and field ownership can be confirmed for your team. Start with the mapping you can explain and test, then decide what is ready to extend.