The Model Is Rarely the Problem: Integrating AI into SAP, Microsoft 365 and Jira

The questions worth asking early are concrete ones: how does the AI access documents in SharePoint? How are permissions from Microsoft 365 carried over? How does an AI-generated item land directly in Jira or SAP? Before we start, answer three questions about your planned use case:

1. Does the result need to be available within seconds?
2. Does the process touch several systems at once?
3. Does the request volume fluctuate strongly or is it hard to predict?

Your answers usually already point to which of the three integration patterns below fits.

Why AI projects rarely fail because of the model

We see this situation in enterprise AI projects again and again: a proof of concept convinces. Documents are read correctly, emails classified cleanly, answers look plausible. Then the project stalls. The model is as good as before, but suddenly other questions come up:

1.Where does the AI get its data?

Rarely is everything in one place. Clarify early which systems are the source and through which interface they provide their data.

2.Is it allowed to see the same information as the employees?

The AI should work within your existing permission model and see no more than the person who does the same task.

3.How do results get back into SAP, Jira or Microsoft 365?

An AI that only reads creates another silo. Value comes when results flow directly back into the system where the work happens.

4.What happens when a target system is unavailable?

Outages and maintenance windows are part of daily operations. A production-ready system needs a clear answer and keeps running in an orderly way when errors occur.

5.Who is responsible for permissions and traceability?

Access and auditability need a clear owner. This is often where the security review decides between progress and standstill.

For many enterprise processes, model quality is no longer the limiting factor. The bigger task is implementing data access, permissions and system integration cleanly. What separates a convincing demo from a system used every day is above all the connection to the systems where the work actually happens.

Why integration saves time

When AI lives in a separate tool, a new data silo often emerges. Employees copy information into it, check the results and transfer them back into ERP, CRM or ticketing systems. The promised automation then ends at a manual interface. Integration removes that bridge: the AI reads data where it is created, processes it and writes the results straight back into existing workflows.

That is why we treat integration as an architecture decision at the start of a project.

Three integration patterns for most enterprise processes

Which route fits depends on how close to real time the process has to be, what your systems expose and what your security team approves. These three patterns cover most enterprise AI processes.

1.API-based integration: direct and synchronous

The cleanest option when the target system offers a documented interface. The AI service calls the API directly to read and write, for example SAP via OData or BAPI/RFC, Microsoft 365 via the Microsoft Graph API, or Jira via its REST API. The same applies to most modern enterprise tools and in-house systems with an interface.

This suits processes that need a result almost in real time: a ticket comes in, the AI classifies it, and the result is in the system seconds later. The trade-off is tight coupling. The AI service needs credentials, network access and resilience against rate limits and outages of the target system. The friction often sits behind the API: a core system that only exposes data through an older interface, or permissions that cannot be carried over cleanly.

2.Event-driven integration: asynchronous and decoupled

Here the components communicate through a message queue or event bus. An incoming email lands in a queue, the AI picks it up when ready, processes it and makes the result available for the next step.

This pattern fits high or fluctuating volumes, such as the daily email load behind the processing for Fr. Meyer’s Sohn. It decouples the AI’s processing speed from the source system, absorbs load peaks and keeps a brief outage of one component from holding up the whole chain. It requires additional infrastructure and the operational discipline that asynchronous systems demand.

3.Middleware and integration layer

For workflows across several systems, such as ERP, CRM, email and a file system in one process, a dedicated integration layer sits between the AI and your systems. It handles authentication, data mapping, format translation and routing in one controlled place.

This is the most robust pattern for complex workflows and the easiest to audit. It is also the most effort, so it pays off for processes whose complexity justifies it. A common upstream question surfaces here: when several systems hold versions of the same data, which one is the leading source? The integration layer makes that decision explicit.

In practice, a process often cannot be assigned to a single pattern. Depending on the systems involved, several approaches are frequently combined. The patterns are not tied to a fixed product landscape: integration uses the systems already established in the company, such as SAP, SharePoint, Azure, Jira, email systems, file servers or in-house software.

Just as important are the specifics of a process that cannot be read from the system landscape. They are best worked out with the business units who know the actual workflows and exceptions. The patterns set the technical approach, and the domain experts make sure the special cases are covered.

Two questions to settle early

1.How does the AI fit into your permission model?

An AI should follow the same rules as the people in the company. In practice, existing roles, permissions and access models from systems such as SAP, Microsoft 365 or Jira are carried over. The AI only gets the rights it needs for its task.

A simple guideline: the AI accesses no information that is closed to the person whose work it supports or automates.

This is where projects most often run into delays. Access concepts are considered late, necessary permissions are missing, or the security review uncovers open questions. Settling these topics early avoids hurdles later on.

2.Where does a human stay involved?

Not every process has to be fully automated. It often makes more sense for the AI to handle standard cases on its own and hand over to employees only when it is uncertain or meets an exception, such as invoices that do not match the order or emails with an unclear request. People step in where context, experience or a decision is needed.

Defining this handover point early creates transparency and traceability. It also raises acceptance, because it is clear when the AI decides and when a person takes over.

On-premises, cloud or hybrid?

The operating model and the integration architecture influence each other and are best decided together. When regulation, data protection or internal security policies require it, AI components run fully on-premises or in the cloud.

The operating model changes little about the basic integration patterns. The differences lie in where the individual components run and how the connections between them are secured.

About theBlue.ai

theBlue.ai is an enterprise AI company with offices in Hamburg and Poznań and part of the Apollogic group, with more than 120 developers and partnerships with SAP and Microsoft. Because the team comes from enterprise IT, every project starts with the process. We find the manual workflow that costs your company the most and build the AI system for it: integrated into the tools your team already uses, run on-premises or in the cloud, and built to pass your security review. More than 100 automation projects across ten industries stand behind this. Find out more on our About us page.

Frequently asked questions