Connecting to AFAS Profit

With AFAS your own administrator decides what an integration is allowed to see, and that is where it starts.

Connectors are the core

AFAS works differently from the other packages. You do not address a fixed list of endpoints the vendor designed, but connectors that have been set up inside your own AFAS environment.

There are two kinds. A GetConnector reads data out of AFAS, and your administrator decides which records and which fields come out of it. An UpdateConnector writes data in, with AFAS validating first and only creating the record once it checks out.

The consequence follows immediately. A field your administrator has not put into a GetConnector does not exist for the integration, however plainly it appears on the AFAS screens. Discover that during the build and you are waiting on someone else.

Getting access

Sign-in runs on an AppConnector token, which belongs in your AFAS environment and is tied to the connectors you release. Your software also needs the address of your own AFAS environment, because that differs per customer.

The practical side is therefore mostly an arrangement inside your organisation. Someone with administrator rights in AFAS sets up the connectors and issues the token. If you use AFAS through a partner, that is often who does it.

Why this sets your timeline

With Moneybird the building starts on day one. With AFAS it starts with a conversation about which fields the integration needs, followed by someone actually creating those connectors.

That is not an objection to AFAS, and the package is more explicit about it than most. It does mean an estimate without that list is worth little. So we ask early for the connector definitions or for a conversation with your AFAS administrator, and only quote a price after that.

Which fields the integration has to read, written out down to field level
Which records the integration may create or change, and which it may never touch
Who creates the connectors, and when that person has time
Whether there is an environment where testing can happen without touching the live administration

What we build here

We build AFAS integrations as part of custom software and portals. Think of a client portal showing data from AFAS, a request form writing a record into it, or software keeping hours and projects in step with AFAS.

Because the connectors set the boundary, our proposal looks slightly different here: first the list of fields and connectors, then one price and one delivery date. That way no figure sits under a plan whose scope is still open.

Sources

Frequently asked questions

We have no AFAS administrator of our own. Is it still possible?

Yes, but it runs through your AFAS partner or consultant. Arrange that early, because the connectors come from their side and their calendar then shapes the timeline too.

Can you create the connectors for us?

We can write down exactly which connectors and fields are needed and look over your shoulder while they are set up. Creating them happens in your environment, by someone with the rights for it, and that is how it should be: you keep control over what leaves the system.

What if a field has to be added later?

The connector gets extended and the integration adjusted. It is not big work, but it is work on both sides. That is why we ask slightly wider up front than strictly seems necessary.

Does this work with AFAS on our own servers?

The setup with connectors and a token is the same; the address your software talks to differs. Mention it in the intro call and we will look at what your situation needs.