115 questions managing directors and IT leaders actually ask us.

An AI agent is software that handles a task from start to finish, much as a colleague would. Take an incoming order: the agent reads it, checks it against the master data in your ERP, creates the sales order and only flags the cases where something does not match. Unlike a chatbot, it does not wait to be asked. It works through tasks, using tools such as SAP, Dynamics 365 or SharePoint, and it has its own identity with tightly limited permissions. At Haavest, agents run in the customer's live environment from day one, and that is where they stay once they are part of everyday operations. More on AI agents.

A chatbot answers questions; an AI agent gets the work done. A chatbot will tell you how to raise a credit note. An agent checks the invoice and then raises the credit note itself, and if the amount is above the approval limit, it asks a person to sign it off first. Technically, that means the agent has access to systems, its own identity and a log of every step it takes. It also has logic that plans a sequence of steps and carries them out. A chatbot needs none of this, because its job is done once it has answered.

Microsoft 365 Copilot is first and foremost an assistant for people. It helps you draft an email, summarises a Teams meeting or finds a document, whenever someone asks it to. Copilot can now be extended with agents as well, but at heart it is still there to help individuals. An AI agent, by contrast, works without being prompted and has its own permissions in your business systems. It might, for example, go through every new delivery note at three o'clock each night. The two complement each other well: Copilot makes individuals faster, while agents take over entire processes. Many of the companies we speak to start with Copilot. A few months in, they realise the recurring processes have not gone anywhere. That is exactly where agents come in.

Further reading from Microsoft: Microsoft 365 Copilot overview

RPA (Robotic Process Automation) clicks through predefined paths in a user interface. If a screen looks different or a document does not follow the template, it stops. An AI agent, on the other hand, understands the content. It can still read an invoice after the supplier has changed the layout, and it decides what to do based on rules and context. The trade-off is that it is not 100% deterministic, which is why approvals, logging and test cases are built in from the start. In practice, agents are replacing many fragile RPA bots. For purely mechanical steps, though, a conventional workflow is often still the better choice.

If every step is defined in advance and the inputs are cleanly structured, a workflow in Power Automate or Logic Apps will do the job. It is cheaper and easier to audit. An AI agent comes in once the task requires understanding: unstructured emails, documents in varying formats or decisions that call for judgement. We often combine the two. The workflow moves the data, the agent reads, checks and decides, and a workflow then writes the result back to the ERP.

Agents are good at reading and classifying documents, reconciling data across systems and deciding standard cases according to rules. They can also draft replies or quotes and pass the exceptions, and only the exceptions, to the right people. They are poor at decisions with no clear criteria, at processes where every mistake is immediately costly, and at anything that depends on data your business simply does not have. In the assessment we tell you plainly which of your processes fall into the first group. In our experience, it is more than most people expect, but less than some vendors promise.

Yes, language models can make things up, and an agent without safeguards would eventually do the same. That is why we never give our agents free rein. They may only use tools with defined inputs and outputs. Every figure must come from a source recorded in the log. Anything written to the ERP is checked against validation rules. And before every update, the agent has to pass test cases drawn from real transactions. What remains of hallucination in live operation is a measurable error rate, which you can compare with the error rate of doing the work by hand.

First, the mistake is spotted, because every step is logged. When the agent is unsure, it hands over to a person rather than guessing. The case is then corrected, just as you would correct a colleague's typo. We look at the root cause: a missing test case, a gap in the rules or a data problem. For emergencies there is a kill switch that lets the department responsible stop the agent immediately. The monthly report shows you the error rate as a hard number, not a gut feeling.

The agent does the groundwork; a person makes the call where it matters. The department responsible decides which cases those are: every credit note over €5,000, for example, every new customer, or anything where the agent rates its own confidence as low. Approval requests appear where people already work, usually in Teams or Outlook, and a single click is enough to approve, reject or amend. After a few weeks of live operation, you can adjust the thresholds based on the figures. Often they go up, because trust has grown.

In our projects, agents take over the part of the job everyone used to complain about: retyping, reconciling, chasing and forwarding. The people stay. They handle the exceptions, the customer conversations and the decisions, which is what they were hired for in the first place. To be honest, though, in teams where 80% of the work is routine, roles do change shape. That needs to be discussed early, including with the works council. We have yet to see a company cut jobs because of an agent. The backlog of work that had been left undone was always bigger.

Monday morning: 80 orders have arrived as PDFs in the shared mailbox. Until now, someone spent the whole morning typing them into SAP. The agent reads each order, checks the customer, item numbers and prices against the master data, and creates the sales order. Twelve orders have a problem, such as an unknown item or a price that does not match. At 8:15, those twelve, and only those, appear in Teams for the sales administrator, each with the agent's proposal and a one-click decision. By nine, the inbox is empty. At the end of the month, the report shows how many orders the agent created and how often a person had to step in.

No. Most of the agents we build do not have one at all. They are triggered by events, such as a new email, a schedule or an entry in the ERP, and only get in touch when they need a decision. Where people do need to talk to an agent, we use Microsoft Teams. It is already in place and nobody has to learn a new application. A chat interface is an option, not the heart of the matter.

With one specific task that is eating up time today. You do not need an all-encompassing strategy. Look for the process where someone regularly copies data from documents or emails into a system, then work out how many hours a week it takes. Bring that one process to an initial call with us, or go straight to the free Short Assessment. Afterwards you will know whether it is worthwhile and what it will take. Everything else, such as a data platform or governance, follows on from the first agent.

The Short Assessment is our way of getting started with you at no charge. Together with your department and your IT team, we choose one process, look at the systems and data involved and check whether an agent can work reliably there. We start with the process and the figures behind it. Next come access, data and permissions. Finally, we run a first case end to end on real examples. At the end you receive a written assessment covering effort, benefits and risks. You are then free to decide whether to continue, and with whom. Get in touch via the contact page. You will hear back from a member of our team who specialises in your area.

A good first candidate has four characteristics. It happens frequently, at least a few dozen times a week. The rules are known, even if they exist only in the head of an experienced colleague. The data sits in systems you can access. And a mistake can be put right rather than being disastrous. Typical candidates are order entry, invoice checking, quote preparation and complaints handling, as well as keeping master data up to date. What does not make a good first choice is the most complicated process in the business, the one nobody has ever properly written down.

That depends less on the agent than on your organisation. We give you a timeline for your process after the Short Assessment. The route is always the same: assessment, build, testing with real cases, then a gradual handover to the department. The agent logic is rarely what takes longest. Access, permissions and data quality usually are, which is exactly why the assessment tackles them first. Subsequent agents are quicker, because identities, logging and operations are already in place.

For the assessment we need three things. First, someone from the department who actually does the work and can spare around two hours a week. Second, a contact in IT for access and questions about your environment. Third, 20 to 50 real example cases, anonymised if you prefer. A Microsoft 365 tenant and an Azure subscription help, but they are not essential, as both can be set up. What we do not need is complete process documentation or a data platform.

The department is the client. It knows the process, provides the examples, sets the approval thresholds and ultimately judges whether the agent is doing a good job. IT provides the environment, assigns the agent's identity and permissions, and reviews security and data protection. Later on, it either takes over operations or supports them. We sit between the two, translate in both directions and do the building. Projects with only one side at the table usually come unstuck at handover, which is why we insist on involving both from the outset.

Not for the first one. It works directly with the systems where the process takes place today, such as SAP, Dynamics 365 or a mailbox. A data platform such as Microsoft Fabric becomes important in three situations: when several agents need the same data, when an agent has to analyse data from many sources, or when you are overhauling your reporting anyway. For many of our customers, the platform follows the second or third agent, by which point it is clear which data is actually needed. More on the data platform.

The agent is developed in the customer's environment from the first week, with a real identity, real permissions and real data. Initially it handles only some of the cases, or everything it does requires approval. Going live therefore does not mean migrating anything. It means raising the approval thresholds and starting the monthly report. That closes the gap in which, in our experience, most AI projects get stuck.

The platform assessment is for companies that want to build their data and reporting on Microsoft Fabric, or migrate to it. We review your sources, existing reports, data models and usage, and estimate capacity and effort. You receive a proposed target architecture, with the order of work and the risks. The price is agreed up front, however many questions come up along the way. The result is a sound basis for a decision, and one you can act on with or without us.

It is a 30-minute call on Teams or by phone with a specialist in your area. You tell us about the process or data issue on your mind. We ask questions, tell you honestly whether we think it makes sense, and suggest the next step. There is no presentation and no sales pitch. You can arrange a call via the contact page.

A specialist from our team who can actually answer your question. Every enquiry goes straight to the person who knows the subject.

That depends on three things: how many systems the agent has to connect to, how clean the data in those systems is, and how many exceptions the process involves. An agent that takes orders from emails and enters them into a well-maintained Dynamics 365 costs considerably less than one that has to analyse contracts from 15 years of file shares. That is why we quote after the Short Assessment, as a fixed price for the build. If you do not run the agent yourself, a monthly fee for operations comes on top. So do the ongoing Microsoft costs for models and compute, which the monthly report shows in euros.

Because a figure without the process behind it would be either wrong or meaningless. Here is what we commit to instead. The Short Assessment is free. Building an agent and the platform assessment are charged at a fixed price. Operations are covered by a monthly fee. So you know what each decision will cost before you make it. We work in manageable steps, each with its own fixed price, which keeps things safe for both sides.

The fixed price applies to a clearly defined service package: for example, an order entry agent connected to your mailbox and SAP, including approvals in Teams, logging and handover to your team. Whatever is in the quote, we deliver for that amount. A sound estimate depends on knowing the process well, so we feel our way in and work in steps rather than one large package. Each step has its own fixed price, which keeps things safe for both sides. If you want something extra along the way, we discuss it and add it at a new fixed price. The first step is priced on the basis of the assessment.

It covers monitoring the agent and responding to errors and outages, updating models and libraries, and maintaining the test cases. Minor changes to rules and approval thresholds are included too. Once a month you receive a report with the figures: cases handled, interventions, error rate and Microsoft costs. It also covers open queries, what changed that month and what we recommend next. The Microsoft costs themselves are not included, as they are billed under your own contract. Nor are larger enhancements, which would again be quoted at a fixed price. Term and notice are set out in your contract. More on Managed Services.

On the benefit side are the hours currently spent on the process, multiplied by the hourly rate, plus any change in error costs and turnaround times. To take an example: 80 orders a day at four minutes each adds up to more than five hours a day, or around 1,200 hours a year. On the cost side are the fixed price, the monthly fee and the Microsoft costs, which we estimate in the assessment. If the agent will not pay for itself within 12 to 18 months, we usually advise against it, or suggest a different process.

It pays off when a process happens often and takes up time, especially if it is currently handled by skilled people who really have better things to do. It does not pay off if the process only comes up a few times a month, if every case is different, or if the data is so scattered that you would first need a data platform, which on its own would not deliver any benefit. We work through the numbers with you in the assessment, and "no" is one of the possible outcomes.

There are three main items. First, the model calls in Microsoft Foundry, billed according to the amount of text processed. Second, compute for the agent itself, for example in Azure Container Apps. Third, depending on the architecture, storage or a Fabric capacity. For a single agent handling a few hundred cases a day, this typically comes to somewhere between double figures and the low hundreds of euros a month. Exact figures depend on document length and the choice of model. We set budgets and alerts in Azure, and the monthly report shows the costs for each agent.

Further reading from Microsoft: Deployment types for Foundry Models

Yes. Germany, Austria and Switzerland all have national and regional programmes supporting digitalisation and AI in mid-sized businesses. Some offer grants for consultancy, others for implementation. Because the programmes and their conditions change frequently, we deliberately do not quote any amounts here. In the initial call, we can tell you which programmes might currently suit your project and your federal state. We also provide the project description that an application requires. The application itself remains with you or your tax adviser.

Microsoft supports certain projects through partners like us, for example Data & AI workshops, pilot phases on Azure or migrations to Fabric. At times this includes funded services or Azure credits. We are happy to check which programmes are currently running and whether your company qualifies, as the terms change every six months. As a Microsoft Solutions Partner for Data & AI, we have access to these programmes. We would not base a plan on them, but they often help you get started.

Nothing. The assessment is free, and you are under no obligation to work with us afterwards. We do it because we want to give you a fixed-price quote at the end, and to do that we need to understand the process properly. What it does cost you is your people's time: around two hours a week from the department and a few hours from IT.

By setting limits from the outset. Every agent has a budget in Azure, with an alert at 80%. The model is chosen to suit the task, not because it is the biggest one available. Long documents are cut down to what is needed before they go to the model. The monthly report shows the costs per agent and per case, so you can see an agent getting more expensive before the invoice arrives. The same applies to Fabric capacity: we prefer to start small and only scale up when needed. One thing to bear in mind: an Azure budget only sends alerts; it does not stop any resources. So every alert needs someone to act on it.

Further reading from Microsoft: Create and manage Azure budgets

The Microsoft stack your IT team already knows. Microsoft Foundry provides the models and evaluation, the Microsoft Agent Framework holds the agent logic, Azure Container Apps is the runtime and Entra ID manages identities. For data we use Dataverse or Fabric, and wherever people are involved, Teams is the interface. Everything runs in your Azure subscription and your Microsoft 365 tenant, and the code lives in your repository. Where it makes sense, we use open-source components. There is no proprietary Haavest platform to tie you to us.

Further reading from Microsoft: What is Microsoft Foundry?

Microsoft Foundry is Microsoft's platform for accessing language models and the tools that go with them: model catalogue, evaluation, safety filters, logging and deployment. Two things matter for businesses. The models can run in Azure data centres, for example in Germany or Sweden. And Microsoft's enterprise terms apply, so your data is not used for training. Where a request is actually processed depends on the deployment type: Global can process it in any Azure region, Data Zone EU keeps it within the EU, and Standard keeps it in the region you choose. We use Foundry as the model gateway for our agents. It is also where we run the tests that compare quality across model versions.

Further reading from Microsoft: Deployment types for Foundry Models

Whichever model suits the task, not whichever happens to be in the news. Microsoft Foundry gives access to models from OpenAI, Anthropic, Mistral, Meta, DeepSeek and others, as well as smaller models for simple classification tasks, which are faster and cheaper. An agent can use different models for different steps: a small one for sorting, say, and a large one for reviewing a contract. For us, switching models is not a rebuild. It is a configuration change that has to pass the test cases.

Further reading from Microsoft: Overview of Microsoft Foundry Models

The Microsoft Agent Framework is an open-source framework from Microsoft that developers use to build agents in languages including Python and .NET. It handles how an agent calls tools, plans a sequence of steps, works with other agents and keeps its log. It is the direct successor to Semantic Kernel and AutoGen, and brings the two together. For you, this means your agents are built on standard code that runs in your environment, and any team that knows Python or .NET can develop them further, not just us.

Further reading from Microsoft: Microsoft Agent Framework overview

Agents run for long periods, wait for events and sometimes take minutes to complete a single case. That suits a container better than a short-lived function. Container Apps can scale down to zero replicas when there is no load, at which point no usage charges apply. It comes with identity via Entra, logs to Azure Monitor and does not require you to run Kubernetes. If you already have an AKS cluster, you can run the same container there instead. The choice is pragmatic, not dogmatic.

Further reading from Microsoft: Scaling rules in Azure Container Apps

A Dataverse agent is an AI agent that keeps its data in Microsoft Dataverse and works from there. Dataverse is the database behind Dynamics 365 and the Power Platform. This approach makes sense if your processes already run in Dynamics 365 Sales or Customer Service. The agent then finds the tables, permissions and validation rules it needs already in place, and nothing has to be stored twice. Business Central has its own database, but it can be connected to Dataverse through virtual tables. We often build agents like this to complement Copilot Studio once its built-in capabilities are no longer enough. More on Dynamics 365 and Power Platform.

Further reading from Microsoft: What is Microsoft Dataverse?

Yes, and that is our standard approach whenever people are involved. Approval requests arrive in Teams as a card showing the details of the case, with buttons for the decision. If the agent has a question, it asks in the chat, and anyone who wants to can also give the agent tasks there. Nobody has to learn a new interface. Permissions come from Entra, so people use the same sign-in as for everything else. For teams without Microsoft 365, Outlook or a web form works just as well.

Microsoft Fabric is Microsoft's data platform. It brings data integration, lakehouse, warehouse, real-time data and Power BI together under one roof, all sharing a single storage layer called OneLake. For agents, Fabric is where cleansed data from SAP, Dynamics and other sources is held. The agent does not have to search each system separately, and it sees the same figures as the reports. If you already use Power BI, you have usually taken the first step towards Fabric. More on the data platform.

Further reading from Microsoft: What is Microsoft Fabric?

OneLake is the central storage layer in Microsoft Fabric, with one per tenant. It holds tables in the open Delta Parquet or Iceberg formats. Lakehouses, warehouses and Power BI models in Direct Lake mode all access the same storage, so data no longer has to be copied between tools. Shortcuts let you bring in data from Azure Data Lake Storage, Amazon S3, Google Cloud Storage or Dataverse without moving it, and Azure Databricks catalogues can be mirrored. For you, the main benefit is one place and one format, and your data stays readable even if you move away from Fabric one day.

Further reading from Microsoft: What is OneLake?

Direct Lake is a storage mode in which Power BI reads data directly from Delta tables in OneLake. The data does not have to be imported into a model first, and not every click triggers a query against a database. This combines the speed of Import mode with the freshness of DirectQuery. Instead of a long overnight refresh, a short framing operation that simply points to the latest files is enough. Direct Lake requires a Fabric capacity and has limitations, including guardrails for each capacity size and restrictions on calculated columns. When it runs via the SQL endpoint, queries against views or tables with SQL row-level security also fall back to DirectQuery. That is why the platform assessment looks at which reports suit Direct Lake and which are better left in Import mode.

Further reading from Microsoft: Direct Lake overview

You do, entirely. The code lives in your repository, the agent runs in your Azure subscription, the data stays in your tenant and the agent's identity sits in your Entra. During the project we have access, which you can revoke at any time. After handover, we only have whatever access you want us to have for operations. There is no lock-in, and that includes lock-in to us. You can carry on at any time with your own team or another partner; that is what the documentation is written for.

Yes, both reading and writing. We use the interfaces SAP provides for this: OData services, BAPIs via the SAP Connector or, on S/4HANA, the released APIs. The agent gets its own technical user with exactly the permissions the process requires. Every write operation can be traced in the SAP change document and in the agent's log. For analysis across large data volumes, we prefer to move the data into Fabric so that SAP is not burdened with queries. More on Data Engineering.

They can be, if they are built that way. Having Microsoft's name on them does not make them compliant automatically. Four things are decisive. First, the data is stored and processed in your tenant within the EU, and the deployment keeps processing within the EU as well. Second, every processing activity has a legal basis and a defined purpose. Third, the agent only sees the data the process requires. Fourth, every step is logged and can be deleted. For Microsoft Foundry, processing by Microsoft on your behalf is governed by the Data Protection Addendum in the Microsoft Product Terms. We provide the technical documentation your data protection officer needs for their review and, where necessary, for a data protection impact assessment.

Further reading from Microsoft: Data privacy for models in Microsoft Foundry

In your Microsoft tenant and your Azure subscription, in the region of your choice, usually Germany West Central in Frankfurt or Sweden Central. Under the EU Data Boundary, Microsoft commits to storing and processing customer data for Azure and Microsoft 365 within the EU, with a small number of documented exceptions. For model calls in Microsoft Foundry, the deployment type also matters. With Global, a request can be processed in any Azure region, so we use Data Zone EU or Standard in an EU region. Nothing is held at Haavest: we have no servers of our own with customer data on them. If you revoke our access, we can no longer see anything, and the agent carries on running.

Further reading from Microsoft: What is the EU Data Boundary?

No. The models Microsoft itself offers in Foundry, including Azure OpenAI, are covered by Microsoft's enterprise terms. Inputs and outputs are not used to train the models, are not passed on to OpenAI or other model providers, and are not shared with other customers. That is what sets the enterprise route apart from public chat services used with personal accounts, where, depending on the settings, the position may be different. For abuse monitoring, Microsoft may store flagged inputs and outputs within your Azure geography and have them reviewed. If you need to rule that out, you can apply for modified abuse monitoring. And if your staff are using public chat services today, a company agent is also the safer option from a data protection point of view.

Further reading from Microsoft: Data privacy for models in Microsoft Foundry

The EU AI Act classifies AI systems by risk. Most agents that handle orders, invoices or documents fall into the low-risk category, where the main requirements are transparency and documentation. High-risk applications, such as those used in HR decisions or lending, carry considerably more obligations. In those cases, we advise bringing in lawyers before an agent is built. Since 2025, every company has been required to ensure that employees who work with AI are adequately trained. We set up an agent inventory and a log as a matter of course, and together they give you the basis for answering questions about how your AI is used. The legal assessment stays with your legal advisers.

In Germany, in most cases, yes. If an agent logs the work of individual employees or assigns approvals to them, it counts as a technical device that could be used to monitor performance or behaviour, and under the Works Constitution Act that triggers co-determination rights. In our experience, if you invite the works council in at the start of the assessment, a works agreement follows quickly. If you only inform them shortly before go-live, you lose a lot of time. We provide a description of the agent, the data and the log in a form that can go straight into an agreement, and we are happy to join the discussions.

First, a description of the process and its purpose, a list of the data categories and systems involved, and the Azure region. Then Microsoft's contracts and product terms covering processing on your behalf, a permissions concept for the agent's identity, and a description of the logging and retention periods. Where needed, the documents for a data protection impact assessment as well. All of this is produced as part of the project, not as an extra document. We invite your data protection officer to the start of the assessment, so that questions come up early rather than at go-live.

Every agent gets its own identity in Microsoft Entra ID, just like a new member of staff. Instead of a password, it uses a managed identity or a certificate. That identity carries exactly the permissions the process requires, such as reading a mailbox and creating orders in SAP, and nothing more. Your IT team can see the agent in the Entra inventory and change or revoke its permissions at any time. Conditional Access for workload identities requires a Workload ID Premium licence, and it only applies to service principals in your tenant, not to managed identities. For AI agents, Microsoft now also offers dedicated agent identities through Microsoft Entra Agent ID. Every agent we build runs under its own identity.

Further reading from Microsoft: Conditional Access for workload identities

Every case, with its timestamp, trigger and the data read, together with the tools called, the intermediate results and the decision taken. It also records who approved the case and the outcome, along with the model version used and the cost of the call. The log is held in your Azure Monitor or Log Analytics, subject to the retention periods your data protection policy sets, which can be configured per table for up to twelve years. It forms the basis of the monthly report, troubleshooting and subject access requests. What we do not log is any content the process does not need.

Further reading from Microsoft: Manage data retention in Log Analytics

A switch that lets the department responsible stop the agent immediately, without having to call IT and without breaking anything. In practice, it is a command in Teams or a button in a small admin interface. It stops new cases from starting and cleanly completes or rolls back those already in progress, and the whole thing is logged. We test the kill switch together with you before every go-live, much like a fire drill. It is rarely needed in practice. But knowing it is there changes how people feel about the agent.

Purview is Microsoft's tool for data classification, sensitivity labels, data loss prevention and auditing across Microsoft 365, Azure and Fabric. For agents, this means two things. If a label such as "Confidential" encrypts a document, the agent can only open it if its identity has usage rights. And whatever the agent does with data appears in the audit log alongside what people do. In Fabric, sensitivity labels are also inherited downstream, for example from a lakehouse to the Power BI models and reports built on it. If you are not using Purview yet, we set it up as part of our governance work.

Further reading from Microsoft: Information protection in Microsoft Fabric

Yes, if the process requires it and there is a legal basis, for example when processing a customer order that includes a name and address. The guiding principle is data minimisation: the agent only receives the fields it needs. Personnel files and health data are kept out unless the process genuinely needs them. Logs contain no more personal data than the case itself. For particularly sensitive categories, in HR for instance, we recommend a data protection impact assessment before anything is built.

Usually, yes. During the build and in operation we have access to your systems, which means we may see personal data even though we do not store it. We have a standard agreement under Article 28 GDPR for this, which your data protection officer can review, and we are equally happy to sign your own template. With Microsoft, you already have a data processing agreement through the product terms, which covers the operation of the platform.

Microsoft Fabric is a platform where all of a company's data work happens in one place. You bring in data from SAP, Dynamics or files, prepare it, store it, analyse it and present it in Power BI reports. Instead of five tools with five contracts and five copies of the data, you have one capacity, one storage layer called OneLake and one interface that looks like Power BI. Fabric runs as software as a service in Microsoft's cloud, so there are no servers for your IT team to maintain. For companies already using Power BI, Fabric is the natural next step.

Further reading from Microsoft: What is Microsoft Fabric?

In four steps. First, an inventory: which sources and reports exist, and who actually uses what? Typically 30 to 50% of reports are no longer viewed and do not need to be migrated at all. Second, the target design, covering lakehouse or warehouse, layers, naming conventions and permissions. Third, the migration itself, carried out in stages, one department at a time, with each stage running alongside the old system until users have signed it off. Fourth, decommissioning the old environment and handing over to your team or to Managed Fabric. The fixed-price platform assessment covers the first two steps.

Our largest reference for this is Telefónica Germany, where around 1,000 reports, and some 300 employees who work with them, moved from Tableau to Power BI, including parallel running and training. For a mid-sized company with 100 to 200 reports, it is considerably quicker. How long it takes depends less on the number of reports than on the number of data sources, and on how much logic is built into Tableau calculations, because that logic has to be translated into DAX. A like-for-like copy rarely makes sense; the migration is an opportunity to consolidate your reports. See our references.

Qlik Sense and QlikView use an associative data model and their own scripting language for loading data. Power BI has neither in that form. The load scripts become dataflows, notebooks or pipelines in Fabric, the data model becomes a star schema with relationships, and Set Analysis expressions become DAX measures. Most of the effort therefore goes into the data layer rather than the front end. We recommend starting with the department that has the most users, so that the benefits show early on.

Microsoft recommends Fabric for new data warehouse projects and provides an upgrade path for existing Synapse environments, so for most Synapse customers the switch is worthwhile. Dedicated SQL pools move to the Fabric Warehouse using the Migration Assistant. Spark notebooks move across with the Spark Migration Assistant and minor adjustments. Pipelines can largely be carried over with the upgrade tool, which is currently in preview. The data lake is connected to OneLake via a shortcut, without moving any data. In the platform assessment, we apply these tools to your existing estate. The main benefits are less to operate and a single price for everything.

Further reading from Microsoft: Migrating Synapse SQL pools to Fabric

Yes, and it is one of the most common scenarios we come across in mid-sized companies. T-SQL logic from views and stored procedures moves into the Fabric Warehouse, which is largely T-SQL compatible. SSIS packages become pipelines or dataflows, or continue to run in Fabric through the Invoke SSIS Package activity, which is currently in preview. SSRS reports move to Power BI. For schema and data, there is the Fabric Migration Assistant, which also supports SQL Server as a source. Fabric reaches source systems in your data centre through an on-premises data gateway, so SAP or your inventory management system can stay where they are. Afterwards, you no longer have to run the server, take backups or apply patches.

Further reading from Microsoft: Fabric Migration Assistant for Data Warehouse

Both store data in the same OneLake and in the same format. The difference lies in the tools. You work with a lakehouse using Spark and notebooks, which suits raw data, files and data preparation in Python. You work with a warehouse using T-SQL, which suits teams from a SQL Server background who need clean tables for reporting. Our usual recommendation is a lakehouse for the early layers. For the reporting layer, use either a warehouse or a lakehouse with its read-only SQL analytics endpoint, depending on where your team's strengths lie. The decision is not irreversible, because the data is in the same format either way.

Further reading from Microsoft: Decision guide: Lakehouse or Warehouse

Fabric is billed by capacity, from F2 to F8192, although the largest sizes are not available in every region. You can pay as you go, with the option to pause, or through a reservation. OneLake storage is billed separately on top. A mid-sized company with a few dozen reports and overnight data loads can often manage with F2 to F8. Larger organisations with many users and Direct Lake need F64 or above. From F64 upwards, users who only view reports no longer need Power BI Pro licences. We start small, measure utilisation with the Capacity Metrics app and only scale up when the figures show it is needed. Actual prices are in Microsoft's price list and change over time, which is why we do not quote any here.

Further reading from Microsoft: Fabric licenses and capacity

It starts with the data model, not the charts. Most slow or contradictory reports do not have a visualisation problem. They have a flat model with no star schema, measures with no clear definition and three different versions of the revenue figure. Good consultancy delivers a model the business understands, measures named in the terms your company actually uses, and row-level security that grows with the organisation. The team includes certified Power BI Data Analysts (PL-300). More important than the certificate, though, is that the team has been doing this for large corporates and mid-sized companies for years. More on Business Intelligence.

Yes, and you should. We migrate in stages, and each stage runs alongside the old system for a few weeks. Users compare the figures in the old and new reports, and any discrepancies are explained or fixed. The old report is only switched off once users have signed off the new one. The cost of running both in parallel is the price of building trust. At Telefónica, that was exactly what made the project a success: in the end, 300 employees made the switch without resistance. The one thing you do need is a firm end date for the old system. Otherwise it will never go away.

Databricks is the right choice if you have a data science team with Spark experience, do a lot of machine learning or deliberately want to stay independent of Microsoft. Fabric is the right choice if Power BI is your reporting tool and your team comes from a SQL and Microsoft background and wants as little operational overhead as possible. You can also use both: Databricks handles the heavy data preparation, and Fabric reads the same Delta tables for reporting, via shortcuts or a mirrored Azure Databricks catalogue. Our advice is independent. For some companies the answer is Databricks, even though that means we will not be the ones building it.

Further reading from Microsoft: OneLake shortcuts

That depends on your SAP system and licence. For S/4HANA and ECC, Fabric Data Factory offers SAP connectors such as SAP Table, SAP HANA and SAP BW. Other options are OData services and CDS views. For larger data volumes and change detection, we use Mirroring for SAP with SAP Datasphere, or alternatively third-party tools designed for delta extraction. One question has to be answered first: does your SAP contract permit extraction in that form? We clarify this with you and, where necessary, with your SAP partner. For the SAP CDC connector, Microsoft explicitly refers to SAP Note 3255746 on this point. SAP Business One is simpler, usually straight from the SQL or HANA database. More on Data Engineering.

Further reading from Microsoft: Extract SAP data to Microsoft Fabric

Managed Agent Ops means we run your AI agents for you, for a monthly fee. We monitor the agents and respond to errors and outages, maintain the test cases and rules, and apply updates to models and libraries. Once a month we send you a report with the figures. The agents continue to run in your environment, and we only have the access that operations require. The service is designed for companies that do not want to build their own operations team, or not yet. More on Managed Services.

Managed Fabric means we run your Microsoft Fabric platform for you. We monitor data loads and capacity and fix errors. When a source changes, we adapt the pipelines. We manage permissions and workspaces and keep capacity costs under control. Every month you receive a report on utilisation, run times and costs. The service includes an allowance for minor changes and new reports. As with our agent service, it is a monthly fee, and the platform stays in your tenant.

Figures, not prose. For agents: cases processed, the proportion handled without human intervention, approvals, errors and their causes, processing time per case, Microsoft costs per agent and changes made during the month. For Fabric: capacity utilisation, the duration and success rate of data loads, report usage, costs and open issues. A further page sets out what we plan to change the following month and why. Your management team can read the report in ten minutes, and it gives them the basis for deciding whether the service is still worth it.

We agree response times according to severity. An agent that has stopped or is writing incorrect data takes top priority. Errors that do not affect operations come next, and change requests are scheduled by agreement. We only offer round-the-clock support if the process genuinely needs it, and we will tell you if we do not think it does. The availability of the platform itself is guaranteed by Microsoft through the Azure and Fabric SLAs. The exact times are set out in the contract and depend on the process.

Term and notice are agreed individually in your contract, depending on the process and the onboarding phase. When the contract ends, the agent or platform keeps running, because everything sits in your environment; what stops is our monitoring and maintenance. In the final month, we hand over documentation, access and any open issues to your team or your next partner. The service should carry on because it is worth it to you.

Handover starts during the build, not at the end. Your team is involved in the decisions, and the code is in your repository from the start. The documentation explains how to add a test case, switch models or adjust a rule. At the end, there are two to three working sessions in which your people carry out typical operational tasks themselves while we look on. After that, you can take over operations completely or bring us in for the odd month when needed. In our experience, one agent needs one person with Python or .NET skills and a little time each week.

For agents, the stored test cases drawn from real transactions are run before every update. The new version only goes live if the results are as good or better, and you can still roll back to the previous version. For Fabric, Microsoft rolls out platform updates automatically. Each month, we check whether new features or deprecations affect your pipelines or reports. All changes are listed in the monthly report. We apply updates on a planned schedule, and straight away only when a security issue calls for it.

Generally available model versions in Microsoft Foundry are usually retired 18 months after launch, and after twelve months new customers can no longer deploy them. Microsoft announces retirement at least 60 days in advance. New models appear every few months. In the managed service, we keep track of all this and test new versions against your test cases before they go live. A new model is often cheaper or more accurate, but sometimes it performs worse on your process. In that case, we stay with the old one for as long as possible. Switching is a configuration change, not a rebuild, because the agent is designed so that the model can be swapped out. One common pitfall is the upgrade setting on each deployment. If it is set to auto-update to the default version, the model changes without any action on your part. If you want to pin a version, you also have to switch off automatic upgrades, and the deployment will then stop responding when that version is retired. That is why we set this deliberately and plan each switch in advance.

Further reading from Microsoft: Model deployment upgrade configuration

Monitoring picks it up before the department does. If cases start piling up or errors accumulate, we receive an alert, and your IT team can receive one too if you wish. After a restart, the agent picks up any cases that were left waiting, without processing anything twice. If in doubt, the department switches back to the manual process until the agent is running again; that process was never dismantled. In our experience, complete outages usually have a cause outside the agent, such as a password changed on an interface. That is exactly why dependencies like these are documented in the operations manual.

The figures do. For every agent, we continuously measure how often people intervene, how often approvals are rejected and how long cases take. If these values shift, that is a warning sign, long before anyone complains. The causes are usually external changes, such as a supplier switching to a new invoice format or a new field in the ERP. In addition, we take a sample of cases every month and read through them, because some errors never show up in any metric.

Yes, in either direction. Some companies take over later because they have since built a team, and then bring us back in for a model change or a new agent. Others start out on their own, realise that operations need more attention than they expected, and hand them over to us. Because everything sits in your environment and is documented, switching either way is a matter of weeks, not months.

In our experience, from around 50 employees. At that size, individual processes have enough volume for an agent to save a noticeable amount of time, and there is someone who can take ownership of the agent day to day. What really matters, though, is not headcount but the number of repetitions. A retailer with 60 people and 300 orders a day has a stronger case than an engineering firm with 200 people working on one-off projects. Our customers range from mid-sized businesses with 50 employees to large corporates such as Telefónica Germany. At their core, the agents are the same.

Almost always the same five: transferring orders from emails and PDFs into the ERP, checking incoming invoices and preparing them for approval, preparing quotes from enquiries, classifying and responding to complaints and service requests, and maintaining and reconciling master data. Depending on the industry, reading delivery notes, inspection certificates, other certificates or contracts may be added to the list. What these processes have in common is that they happen every day, they can be clearly described, and they currently keep skilled people from their real work. You will find examples under Agents and the specifics for each sector under Industries.

Yes. SAP Business One provides a REST interface through its Service Layer, which an agent can use to read and create business partners, items, orders and documents. For analysis, the database can be connected directly, whether it runs on SQL Server or HANA. Typical agents in a Business One environment handle order entry, invoice checking and quote preparation. The key is to give the agent its own technical user with limited permissions, so that the Business One change log always shows what the agent has done.

Business Central is a very agent-friendly system. It runs in Microsoft's cloud and can be accessed via APIs and Dataverse, with sign-in through Entra. What the agent is allowed to do is controlled by permission sets in Business Central. An agent can create sales orders, pre-enter purchase invoices, maintain items and customers, and obtain approvals via Teams, all without anyone having to build a custom interface. For simple steps, we are also happy to bring in Power Automate or Copilot Studio via the Business Central connector. We clarify beforehand which licences this requires. More on Dynamics 365 and Power Platform.

Further reading from Microsoft: Manage access to Business Central

Within limits. DATEV is built for tax advisers and accountants, and opens up through DATEV interfaces and data services. Using these, an agent can, for example, send documents with posting information to DATEV Unternehmen online, or prepare posting batches. What works well is an agent that checks incoming invoices, adds the cost centre and account assignment according to your rules, and passes them on in a structured form to your accounts team or tax adviser. The posting itself stays with the people responsible for it. We use an agent like this for our own invoices and receipts, too.

Yes. Many of the businesses we talk to have one or two people looking after IT, or use an external IT service provider. We need someone who can grant access and answer questions about your environment, and that can be your IT service provider, whom we are happy to work with. We then run operations as a managed service, so nobody at your company has to learn Azure. What you do need is someone in the relevant department who regards the agent as theirs and tells us when it does something daft.

Those reservations are legitimate, and they deserve a specific answer. Specifically: your data is stored and processed in your Microsoft tenant in Germany or the EU, and the deployment keeps processing within the EU. Microsoft does not use the data for training. Access is controlled through your own identities. And you can export everything at any time, because the formats are open. Most mid-sized companies we know already keep their email and files in Microsoft 365, which often holds more sensitive material than order entry does. If a process still must not go to the cloud, we will say so, and we will not build an agent for it.

Further reading from Microsoft: Deployment types for Foundry Models

First, ask your people where they spend the most time retyping, reconciling or chasing, and add up the hours. Second, check where the data for those tasks is held: in systems that can be connected, or in people's heads and Excel files? Third, choose one process and talk to someone who has built something similar before. With us, you can do that in a free initial call or in the three-week assessment. What you do not need at the start is a 40-page AI strategy, a data platform or a Chief AI Officer.

Microsoft 365 is a good foundation. It means identities, Teams, SharePoint and mailboxes are already in place, which is half of what an agent needs. On top of that, you need an Azure subscription for the models and the agent's runtime. It can be set up in an afternoon and is billed purely on usage. You do not need Copilot licences, and you do not need Fabric to begin with. If you still run on-premises Exchange servers and file shares, you should move to Microsoft 365 before your first agent.

During the assessment, around two hours a week for meetings and gathering examples, and much the same during the build. On top of that come a few hours reviewing test results, because only the department knows whether the agent's suggestions are right. In the first few weeks of live operation, approvals take more time because the thresholds are still tight; after that, the effort drops. In our experience, the time invested pays for itself within a few weeks of go-live. And the people who helped build the agent go on to become its strongest advocates.

Not before the first agent, but certainly after the second. The first process shows what works in your organisation, what data is missing and how your people respond to an agent. That gives you a basis for a strategy grounded in reality rather than dreamt up at a desk. Once several departments have ideas, a short framework helps: which processes come first, which rules apply to all agents, who decides and how success is measured. We develop that framework with you as part of AI strategy and enablement, which also includes training for the people who work with agents.

Business Central is Microsoft's ERP system for small and mid-sized businesses. Finance, purchasing, sales, inventory and projects all run in one system, with manufacturing and service available if you need them. Microsoft cites wholesale and professional services as its main focus, but it also supports assembly, production and warehouse logistics. Business Central runs as a Microsoft cloud service, so you do not need servers of your own. It is a good fit if you already work with Microsoft 365, and if you no longer want your processes spread across separate programs and Excel lists.

Further reading from Microsoft: Business functionality in Business Central

Microsoft explicitly positions Business Central for companies that have outgrown an entry-level solution or want to replace an ageing system. Typical warning signs are data maintained in two places, reports that take days to pull together in Excel, and processes that only one person really understands. If, on the other hand, your accounting is lean and runs smoothly, we will not recommend switching for the sake of it. That is exactly what we establish in the free ERP check, before you make any decisions.

Further reading from Microsoft: Introduction to Business Central (training)

Your tax adviser stays your tax adviser and continues to receive their data. With an Essentials or Premium licence, you can get up to three free External Accountant licences, so your adviser's firm can work directly in Business Central. For the transfer to DATEV, we set up an export during implementation, agreed in advance with your tax adviser. Microsoft also recommends defining the data export for digital tax audits together with your tax adviser.

Further reading from Microsoft: External accountants in Business Central

Both are ERP systems for mid-sized companies, and either can support a business well. We are a Microsoft partner and therefore not neutral, and we are upfront about that. The main argument for Business Central is its close integration with Microsoft 365. Business Central data appears directly in Outlook, Excel and Teams, and sign-in and permissions use the same Microsoft identity. If your company already works with Microsoft 365, or wants to analyse its data on Microsoft Fabric, that is a real day-to-day advantage.

Further reading from Microsoft: Welcome to Business Central

Business Central is licensed per user, through Microsoft partners in the CSP programme. There are three options. Essentials covers full use of finance, purchasing, sales and inventory. Premium adds manufacturing and service management. Team Members is for colleagues who only need limited write access. Depending on your needs, there may be further costs for additional environments, storage or the use of AI agents. Microsoft publishes current prices on its Business Central product page. In the ERP check, we work out with you which combination you actually need.

Further reading from Microsoft: Licensing in Business Central

Yes. Microsoft provides a dedicated German version, and the database for an environment with German localisation is hosted in Azure's Germany geography. Among other things, the German version includes the advance VAT return as a file for ELSTER, e-invoicing in XRechnung, ZUGFeRD and Peppol, and the data export for digital tax audits under GoBD. Software alone, however, does not make a company GoBD-compliant. The procedural documentation and your internal processes remain your responsibility. We are happy to help you write them up as part of the implementation.

Further reading from Microsoft: Germany local functionality

An agent signs in to Business Central as an app in its own right, registered in Microsoft Entra, and works through the official interfaces rather than any workarounds. In Business Central, this app is given its own permission sets; the full SUPER administrator permission cannot be assigned to it at all. That way the agent can do exactly what its process requires, and every step is tied to an identity. We work this way ourselves: our agents enter incoming invoices in Business Central, and nothing is posted until our accounts team has checked them. You can see what this could look like for you under Business Central with agents.

Further reading from Microsoft: Service-to-service authentication

Copilot is built into Business Central. You can ask for data in a chat, analyse lists using natural language, have records summarised or get help with bank reconciliation. There are also Microsoft's own agents, such as the Payables Agent, which prepares draft purchase invoices from a mailbox and is billed through Copilot Credits. According to Microsoft, it has so far only been validated for English. These features are only available in Business Central online, and which of them are available in Germany and in German changes with each release. Your own agents pay off where your process extends beyond Business Central, or where your rules do not fit the standard.

Further reading from Microsoft: AI in Business Central

We start with a free ERP check, in which we look at your current processes, systems and data and tell you honestly whether Business Central is the right fit. You then receive a fixed-price quote, in tiered packages depending on scope, so you know what the implementation will cost before it starts. We plan the agents in from the outset, so they are working in the new system from day one. If you wish, we can take over ongoing operations for a monthly fee. More on Business Central with agents.

Yes, and that is often the more sensible approach. You only license the people who actually work in Business Central: Essentials or Premium for full use, Team Members for limited write access. People who only need to look at data occasionally can read shared records in Teams with their Microsoft 365 licence. In terms of functionality, many companies start with finance and purchasing and add inventory, projects or manufacturing later. In our experience, an agent for incoming invoices is a good first step, because it takes work off people's desks straight away.

Further reading from Microsoft: Access with Microsoft 365 licences

We migrate master data such as customers, vendors, items and G/L accounts, using either Excel templates or configuration packages. Configuration packages let you validate the data before it is imported. Open items and opening balances are posted as at the cut-over date, so you start with clean figures. The full posting history does not necessarily have to move across. It remains readable for the retention periods, either in the old system or in an archive. If you want to continue analysing the historical figures, we combine them with the new ones in a data platform on Microsoft Fabric.

Further reading from Microsoft: Import data from other finance systems

Haavest is a consultancy based in Düsseldorf. Since 2016 we have been building data platforms and business intelligence on Microsoft technology, and more recently AI agents as well. Our customers range from mid-sized companies to large corporates. We are owner-managed and a Microsoft Solutions Partner for Data & AI. We take AI agents to the point where most projects stall: live, everyday operation, with real permissions, a full log and a monthly report. What unites us is one conviction: the technology should belong to the customer, not the consultant.

Since 2016, so for ten years now. We started out with data warehousing and Power BI for large corporates, then added data engineering with SAP and Dynamics, and Microsoft Fabric. For some years now we have also been building AI agents. Our size is deliberate: large enough to handle a migration project involving 1,000 reports, and small enough for every enquiry to go straight to the right people.

Our office is at Grafenberger Allee 125 in Düsseldorf. We advise clients in person, on site, across Germany, Austria and Switzerland, and travel further within Europe when needed. Between meetings we work remotely. If you are looking for a Microsoft partner for Data & AI in Düsseldorf, you can reach us via the contact page.

It is a partner designation that Microsoft awards to companies with proven experience in data and AI projects on Azure, including certified staff and successful customer projects. It is based on the Partner Capability Score, which is made up of net customer adds, certifications and customer success, meaning usage growth and deployments. The designation has to be renewed every year. For you, it means our people hold Microsoft certifications, so the expertise demonstrably sits within the company and across the team. We know the Microsoft products from hands-on experience, and we have access to partner programmes that can benefit your project.

Further reading from Microsoft: Partner Capability Score

Within the team, we hold Fabric and Power BI certifications: Fabric Analytics Engineer (DP-600), Power BI Data Analyst (PL-300) and Fabric Data Engineer (DP-700). On the Azure side, there are Azure Solutions Architect Expert (AZ-305) and Azure Administrator (AZ-104), plus a GitHub Copilot certification. For us, certificates are a by-product of our day-to-day work rather than an end in themselves. What matters more is that the same people built the Telefónica migration and the agents for our mid-sized customers.

Our largest published reference is Telefónica Germany, where around 1,000 reports used by some 300 employees moved from Tableau to Power BI, including parallel running, a new data model and training. We have also delivered projects for mid-sized companies in retail, manufacturing and services. Many of these we do not name, at our customers' request, but we are happy to talk you through them. See our references.

With us, the people you meet in the initial call are the people who build your project. We have no bench of junior staff to keep busy and no proprietary platform to tie you to us. You keep the same contact from the first conversation through to operations, and follow-on work comes from good results. The flip side is that we do not have 500 people to run ten projects at once, so now and then we tell you that we can start in a few weeks. Fixed prices in manageable steps are our answer to the question of who carries the risk.

Both, and we have a clear view on this. The start of the assessment, decision meetings and go-live work better on site, because that is where you get to know the people who actually do the work. Build, testing and operations are done remotely, with regular scheduled meetings in Teams and a shared channel for everything in between. We are at our customers' premises regularly in the Rhineland and the Ruhr. For customers in Munich, Vienna or Zurich, we plan on-site days in advance.

Yes, we use several agents in-house, for example for invoices and receipts, time recording and quotes. They run on the same tools, with the same governance and the same monthly report that we offer our customers. There are two reasons for this. We want to know what running agents is really like before we promise it to anyone. And it genuinely saves our whole team time. In the initial call, we will tell you what did not work just as readily as what did.

Retail and wholesale, manufacturing, telecommunications, services and energy: in other words, wherever large volumes of documents, orders and data flow through the business and Microsoft is the foundation. Industry knowledge matters to us. An agent handling delivery notes in manufacturing needs different rules from one handling enquiries in wholesale, even though the technology behind them is the same. Under Industries, we describe what typically comes first in each sector.

At its core, yes, and that is a deliberate choice. We would rather be really good at one platform than half-good at five. Your source systems can still be anything: SAP, Salesforce, databases or files. Databricks or Snowflake alongside a Fabric platform are no problem either.

We are looking for people who want to build and run data and AI solutions on Microsoft technology, not just advise on them. That means data engineers with a Fabric or SQL background, Power BI developers, Python or .NET developers who are keen to work on agents, and consultants who can talk to business teams. We are based in Düsseldorf, work in a hybrid model and make time for certifications. Drop us a few lines via the contact page about what you have built most recently. You will hear back from real people on our team.