You connect AFAS to Power BI through the BI OData connector in Profit: switch on the BI functionality, authorize the BI model, unblock the OData app connector, create a user token, and use that token to connect from Power BI Desktop. Profit data is then staged at most twice a day.
Those five steps are an afternoon of work for someone with admin rights. After that you have a working connection, and that is exactly the point where most projects assume they are finished.
What has not been solved yet tends to sound like this. Someone says in the meeting that the absence percentage cannot be right. Someone else mentions they spent another two hours that morning pulling it out of Profit. And the outcome is that you will look at it again next month. Three remarks, one pattern: the figure exists, but nobody trusts it enough to hang a decision on it.
A connection does not change that on its own. It only moves where the figure lives, from an export on somebody’s desktop to a model in Power BI. So below is first how you make the connection work, and then what you still have to settle before you can steer on it.
How do you connect AFAS to Power BI?
The route AFAS prescribes itself runs through the BI OData connector in Profit. Five steps, in this order:
- Switch on the BI functionality. In Profit under General, Environment, Management, Properties, on the Activation tab.
- Authorize the BI model. The function General, Output, Management, BI model has to be open to whoever is going to build the connection.
- Unblock the OData app connector. Under General, Management, App connector, open the BI OData connector and clear the Blocked checkbox.
- Create a user token. On the User tokens tab of that same connector, tied to a user and with a description that still makes sense a year from now.
- Connect from Power BI Desktop. The OData feed plus that token pulls in the BI models as configured.
AFAS documents every setup step field by field in its own Help Center, in Dutch only, and that is also where to check them, because menu paths shift with a release. On the Power BI side nothing unusual is going on: Microsoft describes the OData Feed connector as an ordinary data source, and it behaves like one.
Keep that token the way you keep a password, because that is what it is. A token sitting in an email or in the description of a shared report is a key to your entire HR and finance administration.
BI OData connector or GetConnector?
Both routes work, and the question is not which one is technically better. The question is which one fits what you are asking for.
The BI OData connector is not an ordinary GetConnector. It delivers everything from the BI models configured in your environment, it is built per customer, and AFAS intends it for BI systems. That makes it the logical starting point: you do not have to work out per table which fields you need.
A GetConnector is one you configure yourself per data collection. More work, and for exactly that reason sometimes the better call:
- You need a field the BI model does not carry. Think of a free field that has taken on a meaning specific to your environment.
- You want to start small on purpose. Pulling one data collection is easier to oversee than a complete model, especially while you are still working out what you need.
- There is logic in the query itself. Filters you would rather define in AFAS than in Power BI, because that is how the rest of the organization already knows them.
In practice most organizations take OData for the base and put one or two GetConnectors beside it for the bespoke part. Start with the model AFAS has already configured for you, and build only what you genuinely cannot find in it.
What to have in place first
Three things, and all three cost more time to repair afterwards than to arrange up front.
Admin rights in Profit come first. Without rights on Management and App connector you will not get past step two, and in plenty of organizations those rights sit with one person who happens to be on holiday.
The second is the license on the Power BI side. Building in Power BI Desktop is free, sharing is not: the moment a colleague has to open the report, that colleague needs a license of their own. What that costs per user and where the tipping point lies is worked out in our article on Power BI licensing and costs.
The third is who gets to see what. The BI model follows the permission structure already in AFAS, filter authorization included, so anyone without sight of an administration in Profit will not see it in the model either. Publish to a workspace of your own and you decide there again who gets in, and that is where row-level security is the instrument. Settle that before the first payroll report goes online, not after.
How current are the figures really?
Twice a day at most. Profit data is staged by a scheduled task, and Power BI cannot pull anything AFAS has not put down yet. A refresh running every hour therefore delivers the same figure every hour.
For almost any steering question that is enough. Absence, margin, revenue per customer and staffing are things you review weekly or monthly, and then a figure from this morning is as useful as one from ten minutes ago. If you do want to watch an operational process live, today’s staffing for instance, an AFAS link is not the tool for it. That is not a shortcoming of the connector, it is a choice in how AFAS is designed.
Useful while configuring: the action that stages a limited set of rows gives you a maximum of one thousand rows per table. That lets you check whether a BI model holds the fields you expect, without waiting for a full load first.
What a connection does not fix
A working connection is plumbing, not a foundation. You can have a technically flawless link and still end up with two reports side by side quoting different numbers, because a connection moves data and does not agree on definitions.
That follows from how AFAS is built, and it is not a criticism. An administration system is designed to record what happened, with the precision a payslip or a general ledger needs. A reporting model is something else: it has to make things comparable, aggregate them, and hold up across years. Three things you therefore still do yourself:
- Settle the definitions. When does an employee count towards staffing: at contract date or at first working day? Without an answer, every absence percentage is an interpretation.
- Inventory the free fields. Free fields carry a meaning in your environment that exists nowhere else. What sits in them is known only to whoever configured it, and that knowledge belongs in the model.
- Build one model instead of four reports. Four reports that each carry their own calculation will drift apart, without fail.
That is why we rarely take on an AFAS link as a standalone job. The connection is the cheapest step of the project. The agreements around it decide whether you are still steering on it a year from now, and that is the same order as data-driven working in general: definition first, screen second.
Now Qlik is gone, you are the administrator
The AFAS Qlik solution stopped on 1 December 2025, and AFAS has run Power BI as its single BI solution since. For most organizations that is an improvement: you are no longer limited to whatever fitted in the standard package.
Something did quietly shift, though. The Qlik dashboards belonged to AFAS, maintenance included. What you get now is a connector and a set of templates, and the building, publishing, securing and maintaining sits with you. That is precisely the freedom you wanted, with the responsibility that comes attached to it.
So three things get named now: who manages the tokens, who owns the workspace the reports live in, and who decides whether a definition may change. A BI environment without an owner runs flawlessly right up to the day somebody goes on holiday.
The standard templates are a fine place to start. Treat them as exactly that: they show what the model holds, not which figures matter most to you. What it costs to build your own version on top, and how long that takes, is set out in our article on getting a Power BI dashboard built.
When to hold off on connecting
There are three situations in which we advise against connecting now.
- No question is waiting for it. A connection built because it is possible produces a model nobody opens. Start with one figure that a decision hangs on.
- Recording in AFAS is inconsistent. If hours go in irregularly or files are half filled out, a dashboard only makes that visible faster. Fix the entry process first, then the reporting.
- Nobody will be maintaining it. Without an owner for the tokens, the model and the definitions, delivery is the beginning of decay.
In all three cases the answer is not never, but something else first. Our approach opens with that question rather than with switching on a connector.
Will that link give you one figure everyone trusts, or four reports that contradict each other? Want to know what your AFAS environment needs to look like to get the first? Get in touch, and we will go through your BI model with you.
Frequently asked questions
Do you need a Power BI license for AFAS data?
Building is free in Power BI Desktop, sharing is not. The moment a colleague has to open the report, that colleague needs a Power BI Pro license. If your organization runs Microsoft 365 E5, Pro is already included and you only have to assign it.
What is the difference between the BI OData connector and a GetConnector?
The BI OData connector delivers everything from the BI models configured in your environment and was built by AFAS for BI tools like Power BI. A GetConnector is one you set up yourself per data collection, so you decide exactly which fields come out. OData is the starting point; a GetConnector covers what it does not carry.
How often is the data from AFAS updated?
Profit data is staged at most twice a day by a scheduled task. A Power BI refresh running more often than that gains you nothing. For steering on weekly or monthly figures twice a day is plenty; for a live operational screen it is not.
What happened to the AFAS Qlik dashboards?
The AFAS Qlik solution stopped on 1 December 2025. AFAS has offered Power BI as its single BI solution since then, with a BI OData connector and a set of standard templates. The difference is not only the tool: building, publishing and maintaining now sits with your own organization.
How do you control who sees which AFAS data in Power BI?
Authorization follows the permission structure already in AFAS, filter authorization included. Anyone without access to an administration or department in Profit will not see that data in the BI model either. Once you publish to a Power BI workspace of your own, you decide there separately who gets in.
Can you combine AFAS data with other sources in Power BI?
Yes, and that is usually why organizations build the link. You put AFAS next to your CRM, time tracking or webshop in the same data model. It does require tying the concepts together: the same customer has to be recognizable as the same customer in both sources.
Do you need technical knowledge to connect AFAS to Power BI?
For the connection itself you need admin rights in Profit and someone who can follow the setup steps. That is an afternoon of work. Building the data model around it and settling the definitions does need someone who knows what a star schema is and why you want one.
