Where Should You Orchestrate an SAP Business Process?
Where Should You Orchestrate an SAP Business Process?
Why Looply can be a powerful orchestration layer for SAP-centric processes that extend beyond SAP
When a new process requirement appears around SAP, the discussion often starts with workflow technology. Should the process be built using SAP Workflow or Flexible Workflow? Should it sit in SAP Build Process Automation on BTP? Does the organisation already have an enterprise orchestration platform that could handle it?
Those are reasonable questions, but they can lead the conversation into product selection too early. A more useful starting point is to look at the process itself. Increasingly, SAP-centric processes are not confined to SAP. They may start with an SAP event, gather additional information from SAP and external services, apply business rules, update another system and eventually write the result back into SAP. Sometimes a person needs to intervene. Sometimes the process can complete without any human interaction at all.
That broader pattern creates an opportunity for Looply. Although Looply is often introduced as a way to extend SAP approvals and notifications into Microsoft Teams, the same platform can also orchestrate the wider process around SAP.
SAP may be at the centre without containing the whole process
A useful way to think about this is to separate the core business transaction from everything that needs to happen around it.
Take supplier creation as an example. SAP may remain the system of record for the supplier, but the process surrounding that supplier can extend well beyond SAP. The business might want to validate a tax number, confirm company-registration information, check an external risk source or retrieve supporting documents before the supplier is released for use.
Those activities do not necessarily need to become part of the SAP transaction itself. Instead, an event in SAP can start an orchestration process that gathers the additional information, evaluates the results and determines what should happen next.
This is where the distinction between workflow and process orchestration becomes useful. The requirement is no longer simply to send something to an approver. The process may need to coordinate several systems, services and decisions before SAP can move to the next business state.
Looply can provide that coordination layer.
Trigger
Start from an SAP event, request submission, document creation or API call.
Enrich
Combine SAP data with information from external services and APIs.
Decide
Automated rule / validation or human judgement when required
Act
Update SAP or another system to complete the business process.
Looply can do more than extend an SAP approval into Teams
Extending an existing SAP workflow into Microsoft Teams remains an important Looply use case. Where SAP already owns the workflow, Looply can surface the relevant work in Teams, provide more useful context and capture the user’s decision without changing where the underlying process is controlled.
But that does not have to be the starting point.
A Looply workflow can also begin directly from an SAP event, an API call, a submitted request, the creation of an SAP document or an event from another business system. From there, it can retrieve data, interact with external services and apply the logic required to decide what happens next.
That next action may involve a person in Teams, but it does not have to.
Consider the supplier process again. A newly created supplier could initially be blocked in SAP. Looply responds to the event, reads the relevant supplier information and calls external services to validate the tax details and company information. If the results meet the organisation’s rules, Looply can trigger the appropriate SAP action and allow the supplier to proceed.
Nothing has been sent to a user. There is no approval card and no notification to action. The process has simply been orchestrated automatically from beginning to end.
That opens up a significantly broader set of use cases for Looply than approval automation alone.
Automate the routine path and introduce people when they add value
The same process becomes particularly interesting when one of those automated checks produces an unexpected result.
Perhaps the tax number cannot be validated, the registered company information does not match the supplier record, or an external risk service returns a warning. Instead of designing the whole process around a human approval, the workflow can take a different path only when one is required.
Looply can gather the relevant SAP information together with the external validation results and present the exception to an appropriate specialist in Microsoft Teams. The user sees why the automated process stopped and has the relevant context available to investigate the case. Once a decision has been made, Looply can continue the original workflow and execute the appropriate SAP action.
That creates a more useful automation principle: automate the normal path and reserve human attention for the exceptions.
This also changes the role of Teams. It is no longer necessarily where the whole workflow happens. Instead, it becomes the point at which human judgement can be introduced into an otherwise automated process.
For some processes that may still mean every case reaches Teams. For others, only a small proportion of transactions may ever require human attention.
External APIs can make the orchestration much richer
One of the strongest reasons to orchestrate around SAP is that the information needed to complete a business process increasingly comes from outside the ERP system.
A supplier process may need tax validation, company information or sanctions data. A finance process might use an external service to validate a transaction or obtain supporting information. A master-data process might compare proposed changes against an authoritative external source. Other processes could incorporate document services, specialist industry systems or AI capabilities.
Looply can call those APIs as part of the workflow and use their responses to determine what should happen next.
This means external information can become part of the process logic rather than something a user must locate manually. A case can be enriched before any decision is required, and in some situations the additional context may allow the process to complete automatically.
Where a person does need to make a decision, the same information can be brought together before the request reaches them. Instead of asking a user to move between SAP, external websites and other applications to establish whether something is safe to approve, the orchestration process can do much of that preparation first.
This is an important shift. The objective is not simply to make an approval faster. It is to make the underlying process more intelligent and more complete.
Looply does not have to replace the wider automation landscape
None of this means that Looply is the only place an organisation could build these processes.
SAP itself provides substantial orchestration capability. SAP Build Process Automation supports rule-based and cross-system workflows and can connect process and task automations to SAP and non-SAP systems.
Many enterprises also have broader automation and integration platforms. ServiceNow may already be established as a strategic workflow platform, while Boomi and similar platforms can coordinate integrations, APIs, events and other automation capabilities. Boomi, for example, now describes its Orchestrate capability in terms of composing workflows across integrations, APIs, event streams and data models.
The point is not that those approaches are wrong or unnecessary. The more practical observation is that organisations already have choices, and adding another orchestration layer is not automatically valuable simply because a new process touches SAP.
Looply becomes particularly interesting where it is already deployed, where SAP remains central to the process, where external systems or APIs form part of the flow, or where Teams may be required for some—but not necessarily all—human interaction.
In those circumstances, it can be worth asking whether the orchestration capability you need is already present.
SAP BTP can still provide the controlled route into SAP
Using Looply as an orchestration layer does not mean removing SAP BTP from the architecture.
In fact, there can be a useful separation of responsibilities. Looply can communicate directly with appropriate external APIs and cloud services, while SAP BTP remains the controlled integration layer into the SAP landscape.
That distinction can be valuable. It means every external service used by the process does not necessarily have to become another orchestration flow inside BTP purely so that it can participate in the business process. At the same time, access to SAP can remain governed through the organisation’s chosen BTP architecture.
The responsibility of each platform is therefore quite clear. Looply coordinates the process. External services provide specialist information or capabilities. BTP protects and controls access into SAP. SAP continues to own the core transaction, business data and logic.
This is not about bypassing BTP. It is about using it where it adds the most architectural value.
Orchestration outside SAP does not mean moving control away from SAP
That separation is also important from a governance perspective.
SAP can remain firmly at the centre of the business process even when the orchestration sits elsewhere. Approver determination can still come from SAP organisational structures, roles or customer-specific logic. Existing delegation arrangements can still be respected. SAP authorisations can continue to determine what a user or integration is allowed to do. Transaction validation and the final business update can remain within SAP.
Looply coordinates those capabilities rather than trying to recreate them.
This is one of the reasons the architecture can remain clean: the orchestration layer does not need to become a replacement for SAP business logic. It can simply bring together the different actions that surround that logic.
Where the process is orchestrated and where business control resides do not have to be the same place.
Existing Looply customers have another reason to consider this model
The argument becomes particularly relevant for organisations that already use Looply.
A customer may initially deploy Looply because it wants to bring SAP approvals into Microsoft Teams. Once that infrastructure is in place, however, Looply is already connected to SAP, already integrated into the organisation’s security and connectivity architecture, and already being used to manage workflow state and system interaction.
Other requirements will inevitably appear. An SAP event may need to trigger a sequence of API calls. An external validation result may need to determine whether a document is released. A new process may need to coordinate changes across several systems before posting a result back into SAP. Another may be able to run automatically in most cases but require specialist intervention when a rule fails.
Not all of these scenarios need a Teams card.
For an existing Looply customer, the important question is whether it makes sense to introduce another orchestration technology for every adjacent requirement, or whether Looply can already handle the process effectively.
That does not mean using Looply indiscriminately. It means recognising that the platform can provide considerably more value than the original approval use case may have suggested.
From SAP approvals in Teams to broader process orchestration
This broader view changes the way Looply can be positioned.
At one end of the spectrum, it can extend an existing SAP workflow into Microsoft Teams without changing the workflow itself. At the other, it can coordinate a fully automated system-to-system process in which no user is involved.
Between those two extremes are perhaps the most interesting scenarios: processes that gather SAP and external data, automate the straightforward steps, and bring people into the flow only when a decision, exception or piece of additional information genuinely requires them.
SAP remains central. Teams remains available where it adds value. External APIs can contribute information and services. BTP can protect access to the SAP landscape. Looply provides the process layer that brings those elements together.
That makes the proposition broader than simply asking:
How do we bring this SAP approval into Teams?
For organisations looking at new SAP-centric automation requirements—particularly those already using Looply—the more interesting question may be:
How much of this business process could Looply orchestrate for us?
Explore SAP-centric process orchestration with Looply
Looply can orchestrate processes across SAP, external APIs, business rules and optional Microsoft Teams interaction, while keeping SAP at the centre of the underlying business transaction.