AFAS integration with your own software

AFAS, the Dutch ERP and HR suite, holds your employees, your projects, your hours or your financial records. Alongside it runs your own portal, your planning tool or your online store. As long as someone re-keys that data, one side always lags behind the other. An integration fixes that, but the work doesn't start in the code. It starts in AFAS itself.

What do you want to connect to AFAS?

Start with the data flow, not the technology. These are the directions you see most often in practice.

• Employees: data from the HR module to your own planning tool, portal or access management.
• Hours and leave: hours logged in your own system sent back to AFAS for payroll or invoicing.
• Projects and sales: projects and orders from AFAS to an application of your own that works with them.
• Finance: invoices, entries and contacts between AFAS and the rest of your systems.
• Documents: file records that belong in AFAS rather than in a shared folder.

Pick one to start with. What each flow involves is covered under AFAS integration, and the most requested combinations are under AFAS and Microsoft 365 and AFAS and HubSpot.

How do you talk to AFAS technically?

AFAS works with connectors. A GetConnector is a set of data you configure and are allowed to retrieve. An UpdateConnector is a configured endpoint you are allowed to write data back to. Access runs through an app connector with a token.

That matters for your planning. A developer can only retrieve something once the connector exists and contains the right fields. Setting that up happens in AFAS, by your administrator or your AFAS consultant. For the exact workings and current terms, check AFAS's own documentation, as it is updated from time to time.

Step 1: have the connectors set up before you build

Make a list of exactly the fields you need, per flow, and hand it to the administrator. Not the whole dataset, only what the receiving side uses. The narrower the connector, the less breaks when something changes in AFAS.

Agree straight away who manages the connector. If a field name changes or a new administration is added, someone has to check that the integration still holds. Without that agreement, you only find out about a change when the flow goes silent.

Step 2: decide per piece of data which system is the source

For every piece of data, name one system that holds the truth. Employee data usually in AFAS, project planning perhaps in your own software, customer data in your CRM. The other systems follow.

Skip this and an address or a contract can be changed in two places, with nobody knowing which version wins. That is the most common reason an integration is no longer trusted after six months.

Step 3: write back with a key, not on a hope

Writing back is the delicate part. A wrong entry or a duplicate line of hours only gets noticed at payroll or invoicing time, and then fixing it is manual work.

So give every message its own key and check it before you write. That way a resend never creates a second line. Test writing back in a separate environment first, with real cases from your records.

Roll out writing back step by step, too. Start with a small group, such as one department or one project, and spend a week checking by hand what ends up in AFAS. Only then add the rest.

Step 4: build in retries and an overview

Integrations fail. A system is down for maintenance, a required field is missing, a value doesn't fit the mapping table. That is normal. What isn't normal is a message disappearing because of it.

Put every message in a queue with its own status and retry it at growing intervals. If it still fails, it lands on a list someone reviews, with the reason in plain language. Alert when a flow goes silent as well: an integration that does nothing is as harmful as one that does the wrong thing.

Where does an AFAS integration usually break?

Four causes come up again and again. First, the connector is set up too broadly, so every change in AFAS affects the integration. Second, there is no owner to make decisions about the mapping tables between AFAS and the other system.

Third, existing data isn't cleaned before the first sync, so duplicate contacts multiply. Fourth, everything is fetched too often instead of only the changes since the last run.

All four can be prevented with the same two agreements: keep the connector narrow and appoint an owner. What else an integration involves, and which other packages can be connected, is set out under integrations.

What does this mean for personal data?

AFAS often holds employee data. As soon as you send it to another system, you are moving personal data, and that needs a lawful basis and an agreement. Only send the fields the receiving system really needs.

Also record how long the receiving system keeps that data and what happens when someone leaves. What you need to arrange for that is set out in EU AI Act and GDPR: what do you need to sort out.

When don't you need an integration?

When the volume is small. Re-keying a handful of changes a week costs less than building and maintaining an integration. If AFAS or the other system will be replaced within a year, you are better off waiting.

If a standard connection does what you need, use it. Building your own makes sense as soon as you need your own logic in the mapping or have to combine several systems. What that costs is set out in what an integration costs and under having an integration built.