Why effective dating matters more than it sounds like it should
SuccessFactors does not simply store an employee's current job title. It stores a sequence of records, each with the date its contents take effect, which is how an HR team can enter a promotion in advance and have it apply on the first of next month rather than the moment somebody typed it.
An integration that ignores this reads the newest row it can find and treats it as today's truth. The visible result is a business card showing a title the employee does not hold yet — sometimes for weeks — or, in a transfer, a department they have not moved to. It looks like a data quality problem and gets reported as a bug in the card, when the cause is an integration that flattened a timeline into a single value.
QRBold reads effective-dated records as effective-dated records. A future change is recognised as future and lands on the day it applies, which is the behaviour anyone who works in SuccessFactors daily already expects and is quietly surprised not to get.
Standard roster or Employee Central: choosing a path
Both paths produce the same kind of card. Which one is right depends entirely on where your instance keeps the authoritative version of the data a card needs.
- The User entity. The default, and sufficient for most instances. It carries name, title, department, email, and phone in one place, and needs only OData read access to User.
- Employee Central entities. For organisations running EC, where job and contact information lives across PerPerson, PerPersonal, PerEmail, PerPhone, EmpEmployment, and EmpJob. More entities to permission, but it reads the records EC treats as authoritative.
- Photos. Optional on either path, and requires the Photo entity to be permissioned for the technical user.
- Custom fields. Available on either path when $metadata is readable, so an instance that keeps a customer-facing title in a custom field can map that onto the card instead of the standard one.
The setup mistakes worth knowing in advance
Two configuration errors account for most failed SuccessFactors connections, and both produce errors that do not describe what is actually wrong.
The first is using a username or an email address where the technical user ID is required. SuccessFactors rejects this at its token endpoint with a message that explains nothing about the cause. The value QRBold needs is the technical user's ID, which is the same string you assigned when you created that user.
The second is omitting "Admin access to OData API" from the technical user's role. The connection still works, but the field-mapping screen cannot read $metadata and falls back to sampling a single record — so any field that happened to be blank on that one person is invisible in the mapping UI, and administrators reasonably conclude the field is not available.
Reading employee records is not the same as handing out cards
The SuccessFactors connector fills a roster and does nothing else. It never creates a card on its own — that is the provisioning engine's job, and it acts only on the rule you set and the preview you confirm.
For an SAP-scale rollout this separation is what makes a controlled pilot possible. You can connect a full instance, verify that the field mapping produces correct cards against real employee records, and still have created none. Then enable one business unit, review the result, and expand on your own schedule.