One row in our Position-to-Job mapping workbook looked complete.

One row in our Position-to-Job mapping workbook looked complete.

Custom Decimal field → SmartRecruiters Job field

It was already marked as mapped.

Decimal is a valid SuccessFactors Position field type.

It is not among the types SAP’s current connectivity guidance lists for mapping into SmartRecruiters.

The mapping document was the problem.

It had answered only one question:

Where should this field go?

It had not answered:

* Native supportability: Is that source and target combination supported?

* Data type: Does the target expect the same type?

* Value semantics: How should nulls, defaults and precision behave?

* Transformation: Stored value, external code, label or mapped value?

* Ownership: Which system owns it after the job is created?

* Test case: What proves the mapping works?

That changes what a useful mapping definition looks like:

Source field | source type | target field | target type | native support | transformation | allowed values | null behaviour | ownership | test case

A valid source field does not automatically make a valid integration mapping.

For me, a row earns the status mapped only when it is supported, transformed where required, owned and tested.

Until then, it is just a row in a workbook.