A governance guide
You just got access to SAP Integration Suite. Building your first integration takes hours. Building a sustainable, governable landscape requires that deliberate decisions are made early. Here’s what to get right before the technical debt starts piling up.
A note on scope: Integration Suite is a broad platform. This guide focuses on Cloud Integration, which is the largest and most commonly used capability.
1. Developer guidelines
Naming conventions are the first building block of governance, but they are just the start. As your implementation grows, developers need a clear reference document that defines the rules for how integrations are built and delivered. Without it, every developer makes their own judgement calls, and consistency erodes quickly.
The developer guidelines should answer the questions that come up on every project. At minimum they should cover:
- Building a new interface: What package does it belong to? What naming applies? What error handling pattern is required? How must externalized parameters be defined and named? What test cases are expected before transport? Who needs to approve it, and what does approval mean?
- Updating or fixing an existing interface: What counts as a change requiring a new transport? When should a version be incremented versus edited in place? Do existing test cases need to be reviewed or updated? Who needs to be informed if behaviour changes?
- Delivery standards: Logging requirements, security rules (no hardcoded credentials, certificates managed centrally, no sensitive data in logs), documentation expectations per iFlow, and how deprecated integrations should be handled and eventually retired.
The guidelines should be a living document, which is updated as the team learns what works and what causes problems. A new developer joining the team should be able to read it and understand what “done” looks like before they touch anything in production.
2. Naming conventions: boring but critical
Without naming conventions, your package list becomes a graveyard of “Test_iFlow_v2_FINAL_useThis” artifacts within a year. Naming conventions must be defined, documented, and enforced before the first real iFlow is built, and the right convention is the one that fits your organisation, not a generic template.
The important thing is to decide deliberately. Consider what information someone needs to identify an artifact at a glance: which domain or team owns it, which systems are involved, what business object or process it handles, and some way to sequence or distinguish it from similar flows. A numeric component is particularly valuable. Something like HR_0003_S4_to_SF_EmployeeReplication makes it immediately clear what the flow does and gives you a stable, sortable identifier that survives renames and refactors.
Apply the same thinking to packages (grouping by domain, team, or system is common), value mappings (what does this mapping cover and for which domain), and externalized parameters (clear enough that someone can configure the right value in a new environment without guessing).
If multiple teams or business areas share a single tenant, your naming convention must also encode ownership. A prefix or segment that identifies the team or project area, such as: HR_, FI_, or SD_. This ensures artifacts are immediately attributable and avoids collisions as the landscape grows. This isn’t just about findability: SAP Integration Suite supports access policies that restrict which users can view or edit specific packages. Pairing a clear naming convention with access policies gives each team a governed workspace within the shared tenant, without needing separate environments.
It also makes sense to use numbers in your naming scheme for both packages and iFlows. A package can be given a numeric identifier such as 30, and the iFlows within it numbered accordingly: 30001, 30002, 30003. This makes artifacts easy to locate and sort, gives you a natural grouping between package and its contents, and provides a stable reference that survives renames. When someone says “check iFlow 30003,” there is no ambiguity.
3. Tenant landscape: how many do you need?
The answer for most enterprises is three tenants:
Development → Test/QA → Production
Each serves a distinct purpose:
- Dev is where developers build, break things, and experiment freely.
- Test/QA mirrors production as closely as possible. This is where integration testing, performance checks, and business validation happen.
- Production is locked down. Only transported, approved artifacts go here.
Fewer tenants to save cost
In practice, many customers run with only two tenants, or even one (not recommended), to reduce licensing and operational costs. A two-tenant setup (Dev+Test / Prod) is workable.
If you go this route, governance becomes even more critical. Without environment separation to enforce discipline, you need stricter process controls: clear branching strategies, role restrictions, and a reliable transport mechanism that keeps development activity from contaminating production. Figaf specifically helps customers in this situation, providing transport and change management tooling that maintains governance even when the tenant landscape is compressed.
4. Transport management: moving artifacts safely
Transporting is where governance either holds or falls apart. SAP provides two mechanisms:
Option A: SAP transport
SAP offers several transport options that support broadly the same pipeline: export artifacts from Dev, move them through a defined route, and require approvals at each gate. They provide an audit trail and approval workflow, and they are relatively cheap.
That said, there are real limitations to be aware of. The SAP tools do not support virtual tenants. After import, users still need to manually apply environment-specific configuration, which is one of the most error-prone steps in any transport. Approvers are also working with limited context: it is difficult to understand what you are actually approving when you cannot easily see what changed between versions.
Option B: Figaf (Recommended)
Figaf is the recommended transport option. It goes significantly further than the native SAP tools in the areas that matter most.
With Figaf you can prepare transports with full dependency management, ensuring related artifacts move together in the right order. Critically, parameters are handled as part of the transport itself, which is typically the hardest part to get right across environments. Approvers can compare versions directly, seeing exactly what changed before signing off. This makes approvals meaningful rather than a rubber stamp.
Figaf also works well in compressed tenant landscapes (two-tenant or single-tenant setups), maintaining governance even when environment separation is limited.
Option C: Manual export/import
Exporting packages and importing them manually. Fine for getting started or for very small teams, but not suitable for enterprise use:
- No audit trail
- Easy to skip Test and go straight to Production
- Environment-specific configuration must be reapplied manually every time
If you do start here, keep a transport log until you move to a proper solution.
Option D: Git
SAP has released a GitHub Actions based flow that enables you to transport integrations through GitHub. It gives you more ability to see what goes on.
Transport rules to enforce
Regardless of the mechanism, define these rules and make them non-negotiable:
- No direct changes in Production. If a hotfix is needed, it still goes through the pipeline, just expedited.
- Externalized parameters must be maintained per tenant. After transport, environment-specific values are set in the target tenant, they are not carried over. In Figaf, configuration is part of the change.
5. Access control: who can do what
Define roles before giving anyone access. SAP Integration Suite uses role-based access with SAP BTP roles. The minimum viable role model:
- Developers: Can create, edit, and deploy in Dev only. Read-only in Test and Prod.
- Technical Approver: Reviews iFlows before they progress through the transport pipeline, ensuring they follow the developer guidelines and meet quality standards. This role is the quality gate between Dev and Production environments.
- Basis: Responsible for importing transports and applying environment-specific configuration in Test and Production. Does not modify iFlow logic.
- Supporter: Has access to monitor message processing, view logs, and investigate errors in production. Enables the support function without granting development or deployment rights.
- Administrators: Have full access, but audited.
The most common governance failure: developers have admin rights in Production “just for emergencies.”
6. Error handling
Consistent error handling is what separates integrations that fail silently from ones that alert immediately. Define a standard before developers start building, retrofitting it across a large landscape is painful and inconsistent.
Every iFlow must have an exception subprocess. When something goes wrong, the exception subprocess determines what happens next: logging the error, alerting, routing to a dead letter queue, or returning a meaningful response to the caller. An error log that says “processing failed” is useless; one that includes source system, target system, message ID, error message, and timestamp is actionable.
How to fix specific errors is up to the developer/supporter. The standard exists to ensure failures are always visible and always recoverable.
7. Monitoring failed iFlows
Having monitoring configured is not the same as having a monitoring practice. The difference is whether anyone is actually looking at it, understands what they are seeing, and knows what to do when something goes wrong.
There are several ways to monitor failed iFlows. The built-in Integration Suite monitoring dashboard is the baseline, it shows message processing status and logs, and is sufficient for initial troubleshooting. SAP Cloud ALM is the recommended option for enterprises already on SAP, providing unified alerting and health dashboards across the SAP landscape. Figaf’s support module goes a step further by adding a workflow around failed messages: the support team can see what failed and why, and reprocess messages, including correcting data errors, without needing developer involvement for routine cases.
Regardless of tooling, establish who owns monitoring before go-live and document the escalation path from a failed message to a resolved issue. Track which interfaces fail most frequently, patterns in error data often point to problems worth fixing at the source.
8. Testing
Testing is one of the most overlooked parts of integration governance, and one of the most valuable. Every iFlow should have test cases that can be run to verify it behaves as expected.
Test cases serve two purposes. First, they validate that a change hasn’t broken something it shouldn’t have. When a developer modifies a shared iFlow, tests are what prevent unintended side effects from reaching production silently. Second, they act as living documentation, a test case that shows inputs and expected outputs tells the next developer more than a comment ever will.
Figaf makes it straightforward to create and manage test cases directly against your Integration Suite. Rather than building test tooling from scratch, you can record and replay message flows, assert on outputs, and run the full suite as part of your transport validation before anything reaches production.
9. Groovy and XSLT development
Groovy scripts and XSLT mappings are where a lot of integration logic lives, and where a lot of time gets lost. Most developers default to free online Groovy editors or writing transformations blind, then deploying to Integration Suite to find out if they work. This loop is slow and frustrating.
The better approach is to develop and test locally against real data with real properties. Figaf includes tooling that lets you run Groovy and XSLT directly against your Integration Suite environment, with the actual message properties and parameters in scope. This closes the feedback loop significantly and catches issues that generic online editors would never surface, because they don’t know anything about your integration context.
10. Documentation
The structural documentation (what an iFlow does, its inputs and outputs, its parameters) can largely be auto-generated. Tools like Figaf can produce this from the iFlow itself, and other options exist. This removes the excuse for skipping it.
What cannot be auto-generated is the reasoning behind the design: why a particular approach was taken, what constraints shaped the solution, what was tried and discarded. That context is what the next person supporting the integration actually needs. An iFlow that is well-documented structurally but has no explanation of its design decisions will still take hours to understand when something goes wrong six months later.
11. Training and developer feedback
Getting developers up to speed on Integration Suite is not a one-time event. The platform evolves, best practices mature, and new developers join. A deliberate training approach prevents the landscape from drifting back toward inconsistency.
Initial training should cover the developer guidelines, naming conventions, transport process, and error handling standards, everything a developer needs before they touch the first iFlow. This doesn’t need to be a formal course; a structured walkthrough with a senior developer, combined with the guidelines document, is often sufficient. The goal is that no developer should be discovering the standards through a transport rejection.
Ongoing training keeps the team current. SAP releases updates to Integration Suite regularly, and new adapters, features, and patterns emerge. Designate someone to track relevant changes and share them with the team. If the team is using Figaf, changes to tooling workflows should be communicated the same way.
Feedback on how developers are doing is as important as the initial training. Review the quality of iFlows before they progress through the transport pipeline, not just whether they work, but whether they follow the standards. Are exception subprocesses in place? Is naming correct? Are parameters externalized properly? The Technical Approver role is the natural home for this feedback, but it should be constructive and specific, not just a gate.
Over time, patterns in transport rejections, failed tests, and monitoring alerts tell you where the team needs more support. If the same type of error keeps appearing across different developers, that’s a training gap. Address it at the source rather than correcting it case by case.
You’re ready to get started
With naming conventions agreed, guidelines written, tenants provisioned, transport tooling in place, roles assigned, error handling standardized, monitoring owned, tests in place, documentation expectations set, and a training practice established, you have the foundations for a well-governed Integration Suite implementation.
Good luck.
