AFAS data read-only, answers only after approval
An employee of your organization asks about their leave balance or a line on their payslip. FixControl reads the named fields it needs from your own AFAS Profit views, filtered on that one person, and writes nothing back. The answer about their own situation is a draft until someone on your team approves it.
What the AFAS Profit connection covers
Read-only by construction
The connection has read methods and nothing else. No leave request, no profile change, no record created in AFAS — FixControl reads what an answer needs and leaves your HR system exactly as it was.
Your own GetConnector views
FixControl talks to AFAS Profit through three GetConnector views you define yourself, with prescribed field ids: employee, leave and payroll. If your system names fields differently, you map them in your own view — FixControl never guesses a field.
One person per call, projected onto named fields
Every call filters on a single person and takes at most one row, then projects the response onto the fixed shape those field ids describe. Widening a view on your side cannot leak extra personal data into an answer.
Credentials per organization
An app-connector token — encrypted at rest — plus your ProfitRestServices URL and the three view names. A half-filled entry is ignored rather than merged with platform defaults, so one environment's token can never be paired with another environment's host.
A connection check, before an employee runs into it
A periodic check reads the employee view with a filter value that can match no person. A revoked token or a rotated secret surfaces as a failing check, an audit event and an administrator notification — not as a failed answer to an employee.
The data is read; the answer still needs a person
What comes back from AFAS does not become an outgoing answer on its own. A question about someone's own situation becomes a draft or a review case, bound to a named reviewer, and a second person approves before it is delivered.
What the AFAS connection can and cannot do
The connection has one health capability on purpose: the connection itself. A single missing employee record is a data condition, not a broken integration, so it routes that one question to a person instead of colouring the connection red for everyone.
Read from the leave view you define, with the as-of date that belongs to the value. Available where that view exists and exposes the prescribed field ids.
An explanation code with an as-of date — never an amount, never a payslip document. Reading it also requires the separate payroll permission on the reader's project role.
Filtering on one person and projecting onto the prescribed fields is not configurable — the raw row never leaves the connector, so it cannot end up in an answer or in a prompt.
A filtered read that can match no employee proves the endpoint is reachable and the token is authorised for that view, without touching a real person's record.
Not part of the connection, at any level. There is no create, update or delete path — no leave request, no absence registration, no profile change.
Out of scope on purpose. The payroll view returns an explanation code and its as-of date; amounts and documents are not read, so they cannot appear in an answer or in an audit record.
A missing value never becomes a made-up one
Questions about the AFAS Profit integration
Does FixControl write anything back to AFAS?+
Which fields does FixControl read?+
What happens if AFAS is unreachable or a value is missing?+
Where do the credentials live?+
Can a project start reading from AFAS on its own?+
Does an answer about my leave balance go out automatically?+
See what an AFAS-backed answer has to pass
Book a demo and follow one leave question from the AFAS read through assignment, approval and delivery.