Loading
Skip to main content

Success Community

Support

Frequently Asked Questions

Find answers about Release Owl platform setup, pipelines, integrations, testing, and SAP release governance.

FAQ Categories

ReleaseOwl is a native DevOps platform built specifically for SAP applications. It brings change management, build, validation, deployment, testing, and release management for SAP On-Premise, SAP BTP, SAP Integration Suite, SAP Datasphere, SAP Analytics cloud, S4HANA Public Cloud, S4HANA Private cloud, MTAR, CAP and RAP Applications.

Yes. ReleaseOwl is offered as a SaaS platform.

Yes. ReleaseOwl is SAP-certified and ISO 27001 certified. It is also designed to support compliance requirements such as GxP and GDPR, helping organizations meet their regulatory and governance needs.

Credentials are registered from Administration under Credential Manager. ReleaseOwl provides distinct credential types for SAP services, ALM tools, ITSM tools, test automation tools, source control systems, and other third-party integrations.

Yes. Wherever a credential form includes a Scope field, you can choose Global, which makes the credential visible and usable by all users, or Private, which keeps it visible only to the user who created it. Choose the scope based on who should be able to see and use that credential.

Credential registration and updates are documented through the Administration web interface. Currently, update through API is not supported. However, we can consider it based on requirements.

Administration includes Component Management, which helps organize software components and can also be used to drive approval routing in release pipelines. In ReleaseOwl, custom components can be created to match how your organization segregates development.

Components are used to segregate areas of development and to route approvals accordingly. Using the Custom assignment type on an Approval Task, specific roles can be mapped to specific components, so an approval request is automatically directed to the right group of people based on the component involved in a user story.

Yes. Freeze Period Management lets an administrator define a start date, an end date, an enabled or disabled status, and the environments that the freeze applies to, so releases can be paused during change freezes such as month end or year-end close.

A release that is scheduled for an environment under an active freeze is put on hold rather than blocked outright. It appears under Waiting Releases and can be resumed once the freeze period ends or is lifted.

The RO Agent is a standalone application that facilitates communication between ReleaseOwl and certain integrations, such as Tosca, executing jobs like test case runs on behalf of ReleaseOwl from within the customer network.

A Callout is a pipeline mechanism used to invoke an external web service or REST endpoint, for example creating a change request in ServiceNow. The RO Agent is a separate, installable connectivity component used for integrations that need an agent bridging ReleaseOwl and the external tool, such as running Tosca test executions.

ReleaseOwl connects securely to on-premise SAP systems through SAP BTP and SAP Cloud Connector.

Yes. Depending on the task or deployment type, ReleaseOwl can notify a specific user, any user holding a given role, a custom recipient, or the user who promoted the change.

User permissions are handled through roles configured under Manage Roles. Each role is built from granular permissions grouped into categories such as Transport Management, Change Management, CPI Management,API Management, SAC Network Item, Pipelines, Release Management and Test Automation. Within a project, a user can be given full Project Admin access, view only access, or role-based access, so permissions can be tailored precisely to what a person is responsible for.

ReleaseOwl is a no code configuration platform, so it is configured rather than custom coded. It offers extensive configuration options across pipelines, approval workflows, roles, components, and integrations, and specific enhancements can be discussed with the ReleaseOwl team where a requirement falls outside standard configuration.

ReleaseOwl is designed for both. Developers use it day to day to manage transports, user stories, and artifacts, while administrators configure environments, credentials, roles, components, and pipelines through the Administration view.

The current Admin Guide documents integrations with Jira, Azure DevOps, ServiceNow, Freshservice, 4me, and SAP Cloud ALM. Also, ReleaseOwl is having own ALM integration supporting scrum and kanban .

The Jira Cloud integration uses OAuth 2.0 and includes configuration for the Jira project and webhooks, so eligible Jira work items can synchronize with ReleaseOwl in near real time.

Yes. Jira Automation Rules can call the ReleaseOwl API when issues are created, assigned, transitioned, or updated, provided the configured conditions are met, keeping the two systems aligned without manual syncing.

A credential is registered with the Azure DevOps organization URL and a personal access token. User stories are then synced from Change Management, and a webhook configured in Azure DevOps Service Hooks keeps updates flowing in both directions, so status changes in either system are reflected in the other.

The SAP Cloud ALM integration synchronizes features, so SAP Cloud ALM can remain the planning and lifecycle layer while ReleaseOwl executes the technical release activities.

Yes. Once synchronized, ReleaseOwl user stories can be linked to technical artifacts such as transports or  artifacts and promoted through a ReleaseOwl release pipeline.

Yes. Technical execution details from ReleaseOwl—including pipeline activities such as Approvals, Validations, Deployments, and Retrofit activities—are written back to SAP Cloud ALM as comments on the respective user story. This provides end-to-end traceability from planning and development through to production deployment.

No, they are complementary. SAP Cloud ALM provides planning and lifecycle visibility, while ReleaseOwl automates the validations, approvals, deployments, testing, and release execution behind those plans.

Yes. ReleaseOwl provides separate integration modules for each ALM and ITSM product, and which ones are active depends on how the project's administration and workflow are configured.

Landscape Mapping is a configuration used to identify and manage dependencies between user stories, both within the same project and across different projects. It helps ReleaseOwl understand the relationships between landscapes and associated user stories to support coordinated release and deployment activities.

User stories act as the business and change container that connects requirements with technical artifacts. They can be synchronized from an ALM tool, enriched with transports or artifacts inside ReleaseOwl, and then promoted through release workflows.

Yes. A ReleaseOwl user story for SAP Integration Suite can associate artifacts from different Integration Suite areas and promote them together through the configured release pipeline.

Yes. User Story Dependencies is available a, letting you define a relationship as Depends On or Dependent On between two stories.

Yes. Dependencies can be defined within the same project or across different projects, subject to the documented project and landscape mapping rules.

No. Dependencies cannot be added to a user story that is already in an In-Progress status.

Yes. User Story Dependencies can be enabled within a Validation Task, and the validation report includes a dedicated tab showing whether the dependency check succeeded or failed.

An auto sequence feature is available at the user story level, so all transports linked to a story can be sequenced automatically.

Transport Management provides a centralized way to create, track, validate,  SAP transport requests across the configured SAP landscape. Also, Critical Objects can be maintained.

No. ReleaseOwl relies on the underlying SAP transport route configuration, so a system that has not been set up in the transport routes cannot receive transports until that configuration is corrected.

Yes. A transport can be imported via Transport of Copies to a chosen target system, letting teams test changes in a downstream environment without releasing the original transport.

A Transport Management Validation Task can run a Release Status Check, Downgrade Protection Check, Cross Reference Check, Cross Release Check, Critical Object Check, ATC checks, impact analysis, unit tests, and User Story Dependencies.

Critical objects are maintained under Manage Critical Objects. An object marked Active requires approval before it can be deployed. If both Active and Whitelist are selected for an object, transports containing it can be imported without additional approval, and any modification to a critical object triggers a warning during validation.

When enabled, the pipeline can proceed even if the selected validation checks report failures. It should only be used where the release policy for that pipeline explicitly permits continuing past a failed check.

ATC checks are configured in the SAP backend, and ReleaseOwl runs the customer's ATC check variant as part of transport validation. Results appear in the ATC Report with findings categorized as errors, warnings, and informational messages.

Yes. Parallel Landscape Configuration supports retrofit from a maintenance landscape back to a development landscape, so fixes applied directly in production support are not lost when a larger project finally goes live.

Transportable ABAP objects and customizing objects can be retrofitted, covering both Workbench and Customizing transports that have already been released.

When ReleaseOwl detects no conflict, retrofit can complete automatically as part of the release pipeline. Where a conflict exists, it is flagged on the Retrofit screen for manual identification and resolution.

Retrofit conflicts are analyzed at a granular level for each object by comparing the changes in the maintenance and implementation landscapes. If the same object has been modified in both systems, ReleaseOwl identifies it as a conflict. The conflict can then be reviewed and resolved directly within ReleaseOwl using its browser-based conflict resolution capability.

When a retrofit is initiated, either automatically through the pipeline or manually from the Retrofit screen, ReleaseOwl analyzes the released source transport and creates the corresponding target transport request as part of the transfer.

A transport request becomes visible on the Retrofit screen based on the retrofit configuration. Typically, it is considered for retrofit once the transport has been released in the maintenance landscape.

Yes. ReleaseOwl integrates with SAP gCTS so ABAP changes tied to transports can be managed through Git enabled change and transport processes, including gCTS Merge, gCTS Activate and gCTS Switch.

Releasing the associated transport pushes the changes to Git immediately. Movement toward QA follows the normal transport import process, so the change reaches the QA branch only once the transport is imported into QA.

Yes. Pipeline execution logs capture gCTS task details and metadata, giving operational traceability and audit evidence for every Git enabled deployment.

Yes. ABAP Version Compare, available under Utilities, compares objects between selected systems and highlights identical objects, missing versions, and differences, with additional options for non versioning and documentation objects.

Yes. The gCTS Merge utility lets users define source and target gCTS environments, repositories, and branches, then execute and track the resulting merge.

The pipeline stops at the failed transport and sends a failure notification. The user story can then be re-promoted with the fix transports added, and the pipeline re-imports the full set while skipping the transports that already imported successfully in the earlier run.

It is available for workbench requests.

Yes. Any modification made to an object, including formatting changes such as those from a pretty printer, is surfaced as a conflict during retrofit.

First register the required SAP Cloud Environment credential, then register the environment itself with details such as name, region, API endpoint, credential, organization, space, and environment type, for example DEV, QA, or PROD.

Yes. Registered environments can be edited or deleted from the environment registration screen.

Build Pipelines fetch source from a Git repository, run early validation, and package the application as a deployable MTA artifact, an MTAR file, ready to be promoted through a release pipeline.

GitHub, GitLab, Azure devops ,Bitbucket and SAP Git are supported.

A build pipeline can be triggered manually, on a schedule, or by a webhook, depending on how the pipeline is configured.

Yes. SonarQube can be configured for static code analysis as part of the build process, using either the default ReleaseOwl SonarQube instance or a customer's own instance.

Yes. Malware scanning can be configured using a registered malware scanning credential as part of the build pipeline.

Yes. The BTP Applications module supports multiple MTA Extension, or MTAEXT, files for a single application, covering different target environments.

The Download Artifact option becomes available after a successful build and downloads the generated .mtar file.

ReleaseOwl focuses on SAP BTP applications packaged as MTA artifacts rather than general purpose Docker image management or deployment to non-SAP public clouds. Requirements outside standard SAP BTP deployments can be discussed separately.

ReleaseOwl integrates with SAP Integration Suite to support CI/CD and release management for integration artifacts like iflows,message mappings,value mappings,script collection, OData,REST,SOAP API Providers covering synchronization, validation, testing, deployment, governance, monitoring, and deployment history.

Yes. CPI Management can synchronize Integration Suite packages and their supported artifacts into ReleaseOwl for management within the platform.

For supported artifact types, synchronization captures metadata such as Modified By and Modified On from Integration Suite, improving traceability of changes.

Yes. Deployment History provides a record of package and artifact deployment activity for traceability across environments.

Yes. CPI Management includes artifact version and comparison capabilities, so differences across artifact versions or environments can be reviewed before promotion.

Yes. Backup and Rollback is supports CPI artifacts deployed to both design time and runtime. Rollback can be enabled within the release pipeline and triggered from pipeline activity when needed.

CPILint validates CPI iFlows against configured rulesets, such as development standards and naming conventions, and reports deviations to support governance and maintainability.

Yes. CPI Governance Rules include CPI Lint and Design Guidelines.

Yes. CPI Management includes iFlow Unit Testing, and unit test runs and results can be reviewed directly, as well as surfaced during pipeline validation.

The CPI Test Generatorhelps to create and automates the execution of regression style tests for iFlows by capturing real messages and turning them into reusable test cases.

Yes. Mock Endpoints simulates receiver responses using recorded messages, replacing live receiver channels with HTTPS receivers pointing to a ReleaseOwl mock service, so flows can be tested without depending on real external systems.

  1. The documented sender adapters supported for CPI Test Generator execution include
  • HTTP Adapter
  • SOAP Adapter
  • IDoc Adapter
  • ProcessDirect Adapter
  • JMS Adapter

 

  1. Process Direct Adapter and JMS Adapter do not have HTTP endpoints, so test cases cannot be executed directly.
  2. To test them, import the CPI Connector Package provided by ReleaseOwl into your CPI tenant.

Yes. Test results provide an expected versus actual comparison, including message, header, and exchange property differences, with an ignore list for values such as timestamps or generated identifiers that are expected to differ.

Yes. The test workflow lets you choose the execution environment and records the environment, run time, and executed artifact version for each test run.

Yes. Integration Advisor management includes synchronization and deployment of supported artifacts MIG and MAGs, along with deployment history.

Yes. B2B Scenario agreements exported from SAP Integration Suite can be imported into ReleaseOwl for management alongside other Integration Advisor artifacts.

A CPI focused Validation Task can include a CPI Downgrade Check, unit tests, User Story Dependencies, and CPI Governance checks include CPI Lint and Design Guidelines.

ReleaseOwl compares the version being promoted against the version already present in the target environment. If the target version is higher, the downgrade check fails validation unless the user story has a force deploy enabled.

CPI Monitoring supports iFlows, Odata,SOAP,Rest APIs letting you drill into any message for error detail. It includes configurable email alerts, an AI based recommendation to help identify the likely cause of a failure, a Code Change view to compare artifact versions around an issue, and the ability to raise a defect directly from an alert, currently integrated with SAP Cloud ALM.

Currently, XML is supported.

Yes. SAP API Management is a dedicated area of the ReleaseOwl user guide covering synchronization, configuration, versioning, association, and deployment of supported API artifacts like API Proxies, API Providers, Key Value Maps and Products

Register the required credential first, then register the SAP API Management environment in Administration before synchronizing or deploying API artifacts.

The current documentation covers API product, API providers API Proxies and Key Value Maps, alongside the related environment and configuration management needed to support them.

Yes. From the project Build area, API Management provides a Synchronize action to retrieve available artifacts and a Sync History log of past synchronization activity.

Yes. ReleaseOwl supports environment specific API configuration, such as target endpoint settings and host aliases, so development values can act as the source while downstream environment values are configured separately for promotion.

Yes. The Revisions area supports comparison across environments and versions, helping teams see exactly what changed before promoting an API proxy.

Yes. API revisions and artifacts can be associated with a user story, so they follow the same governed release process as other change types.

Yes. A pipeline can include API Deployment Tasks for downstream stages such as QA and Production, with approvals configured where required.

Yes. Deployment history and activity logs capture details such as user story, artifact type and version, and deployment status, and deployment notifications include the same information.

"Key Value Map" values can be configured per environment as part of API Management, . Refer to the Key Value Map documentation for the exact deployment behavior expected in your scenario.

Yes. The user guide includes Administration, Public Cloud Transport Management, Validation Report, Deployment Report, and Central Business Configuration for SAP Public Cloud.

Yes. The CBC integration covers credential registration, environment setup, Transport synchronization, release pipeline configuration, user story promotion, and deployment logs for Central Business Configuration content.

Register the CBC credential first, then register the CBC environment in ReleaseOwl following the standard administration flow used for other SAP environments.

Yes. CBC activities can be associated with a user story and promoted through a configured release pipeline, bringing the same governance used for transports and other artifact types.

Yes. CBC release pipelines can include approval steps and notification recipients such as specific users, roles, custom recipients, or the person who promoted the change.

The Deployment Report gives deployment task traceability, including which items were already deployed and skipped, and which activities required manual completion instead of automated execution.

Yes. Deployment logs and reports capture environment, user story and version, status, tenant details, and other execution information needed for audit purposes

Yes. ReleaseOwl integrates with SAP Analytics Cloud for management, deployment, and promotion of SAC artifacts across environments.

It brings SAP Analytics Cloud (SAC) artifacts into the same governed release process used for other SAP technologies, enabling automated approvals,version traceability, and centralized deployment execution, while reducing dependency on manual content transport.

Yes. SAP Analytics Cloud (SAC) OAuth credentials, such as the Client ID and Client Secret, are required to register the SAC connection in ReleaseOwl. OAuth is the supported credential types in Credential Management and must be configured before establishing or configuring SAC connectivity.

SAC packages are synchronized into the project, added to a user story, and promoted through the release pipeline, with deployment status visible from Pipeline Activity and the associated deploy log.

Yes. ReleaseOwl supports deployment of SAP Datasphere Packages.

A SAP Datasphere credential must be registered first, using OAuth credentials, before the environment itself can be registered.

It is registered from Administration under Credential Management using the SAP Datasphere credential type.

Packages are synchronized from the Build section using Sync Packages, and each package's import settings can be configured individually. Deployment history is available from the Actions menu, and packages are promoted through the release pipeline once added to a user story.

Yes.

Yes. Credential Management includes an ABAP Cloud Communication credential type with its own registration procedure.

Yes. Build pipelines for ABAP Cloud support ABAP Unit Test execution, and results are available as an AUnit report in the build execution screen alongside static code analysis results.

A Release Package groups one or more user stories or change items together so they can be validated and deployed as a single governed release entity.

A Release Package can coordinate approvals, validations, deployments, automated tests, task assignments, and user story updates across all of the items it contains.

Yes. A package can contain multiple eligible user stories.

Yes. The creation flow includes an option to auto add eligible user stories, and stories can also be added manually where more control is needed.

Yes. User stories can be reordered within the package, which matters when the release needs to respect dependencies or a specific deployment sequence.

Yes. A preview shows artifact information, such as artifact type, version, and synchronization details, before the package is promoted.

Yes, as long as the user stories have been synchronized into the same ReleaseOwl project, they can be grouped into a single release package regardless of which ALM project they originated from.

A Release Pipeline provides a unified, automated framework for the complete release lifecycle of SAP applications across On-Premise and BTP solutions, orchestrating build, deploy, validate, approve, and promote tasks across stages such as Dev, QA, and Production with audit trails throughout.

Yes. Pipelines can model stages such as Development, QA, and Production, with tasks attached to whichever stage they belong to, supporting continuous delivery across the full landscape.

The task catalog includes Approval, Callout, Manual, User Story Status, Validation, Deployment, Checklist, Test Execution, Message Listener, gCTS Merge, Activate and Switch, Import via Transport of Copies, Transport Retrofit, DocuSign Approval, Test Evidence, Update User Story Fields, and Branch Merge tasks.

A Validation Task runs platform specific quality checks before a release continues, with the available checks depending on the artifact type involved, such as SAP transports or CPI artifacts.

A Deployment Task performs the automated deployment or import action for the selected SAP technology and target environment as part of the pipeline.

A Manual Task pauses the workflow so a person can complete a required manual activity, such as configuration, testing, or verification, before the pipeline continues.

A Manual Task can be assigned to a specific user, any user with a given role, a custom recipient, the user story assignee, or the person who promoted the change, depending on how it is configured.

A Checklist Task presents a set of governed checks or actions to an assigned user in My Tasks and supports an approval or rejection workflow around them along with capability to attach documents wherever it is kept mandatory.

Yes. A Callout Task can invoke a configured external endpoint, such as an ITSM change request creation, as part of the release workflow.

Yes. Test Execution Tasks and configured test tool integrations can be used as quality gates within the release workflow.

Yes. The task catalog includes gCTS Merge, Activate, and Switch tasks for Git enabled SAP transport workflows.

Yes. The task catalog includes gCTS Merge, Activate, and Switch tasks for Git enabled SAP transport workflows.

Yes. Import via Transport of Copies and Transport Retrofit tasks are both available in the pipeline task catalogue.

Yes, for supported pipeline types. For example, MTAR release pipelines support manual and scheduled triggers, and BTP build pipelines additionally support webhook triggers.

Yes. Approval tasks can be assigned to a specific user, to any user with a given role, or, using the Custom option, to different roles mapped against individual components, so multi stakeholder approval matrices can be modelled precisely and even exported for reuse in other pipelines.

Yes. Approval tasks can be configured to require peer review, preventing a developer from approving or importing their own transport.

User stories and tasks from Jira are synchronized into ReleaseOwl. Developers attach transports, CPI artifacts, and other development artifacts to those stories, which are then promoted through the release pipeline from development through to production.

The current Test Automation section covers HCL OneTest, Tricentis Tosca( Cloud and On Prem), UiPath, Worksoft.

ReleaseOwl connects to UiPath Orchestrator through a registered credential and test configuration. Configured test sets can be run from ReleaseOwl, and results can be reviewed directly in the platform.

Yes. The UiPath flow includes test run status and a report covering details such as the test set used and the execution start and end times.

Yes. ReleaseOwl supports Tosca test automation, including Tosca Cloud and Tosca Server. Tosca On-Premises is also supported, enabling automated and distributed test execution as part of the ReleaseOwl release process.`

Yes. HCL OneTest is included in the current Test Automation section, covering test configuration and running automated tests with release pipelines.

Yes. A Continue on Failure option, when enabled, allows the pipeline to proceed even if some unit tests fail, so the choice to apply gate on test failures is left to each pipeline's configuration.

My Tasks is the workspace where users act on workflow tasks assigned to them, including approvals, checklists, and manual tasks generated by a release pipeline.

Open the assigned task in My Tasks, perform the required activity, provide a completion message if the task requires one, and mark it Complete.

Yes. Approvals and checklist driven workflows allow users to Approve and Reject actions directly within My Tasks.

Yes. It ties human decisions and actions directly to the release workflow, rather than leaving approvals and manual steps outside the deployment record.

Deployment Multiverse combines different SAP artifact types into one coordinated deployment request, instead of managing each technology as a separate release.

Multiverse covers mixed deployments involving SAP transports, MTAR applications, Integration Suite iFlows, SAC packages, and other SAP artifact types within a single coordinated release.

Multiverse provides a unified and governed release workflow across multiple SAP technologies, allowing different technology-specific artifacts to be managed, validated, approved, and deployed as part of a single release process. This simplifies cross-technology releases, improves traceability, and reduces manual coordination between teams.

It compares ABAP objects between selected systems and visually identifies identical, missing, and different object versions, with additional options for non-versioning and documentation objects.

ReleaseOwl provides a dedicated Reports section with multiple reporting capabilities, including User Story Deployment Reports and Artifact Deployment Reports. Users can filter reports based on parameters such as start date, end date, and target environment, and export the results in PDF or Excel formats. ReleaseOwl also provides compliance and traceability reports for each user story, enabling teams to track the complete release and deployment history.

Yes. Validation Tasks produce validation results and reports for every quality check executed, supporting both release decisions and later audit review.

Yes. Deployment History is available for CPI packages and artifacts, and for Integration Advisor artifacts deployment activity.

Yes. ReleaseOwl provides a Platform Updates section that displays notifications about new features, enhancements, and platform changes. Users can access the relevant release notes directly from the notification to review the details of each update.

The documentation covers SAP On-Premise, SAP BTP, SAP Integration Suite, SAP API Management, SAP Public Cloud, SAP Analytics Cloud, SAP Datasphere, and SAP ABAP Cloud,

Yes, ReleaseOwl is built to be fully native to SAP, working directly with SAP transport, BTP, and Integration Suite technologies rather than through a generic third party layer.

No, the two are complementary. SAP Cloud ALM provides Project planning and lifecycle visibility, while ReleaseOwl executes the governed technical change and release automation behind it.

ReleaseOwl brings transport management, deployment sequencing, retrofit and conflict resolution, and impact analysis together in a single platform, and extends beyond a traditional ChaRM based process with additions such as CPI monitoring, gCTS support, and integrated automated testing. The specific fit for your landscape is best discussed with the ReleaseOwl team against your current architecture.

Implementation timelines depend on the scope of the engagement, including the number of environments, integrations, and pipelines involved, so there is no single fixed duration. It is best to discuss a timeline estimate with the ReleaseOwl team based on your specific landscape and requirements.

ReleaseOwl is offered as a SaaS platform. If an alternative deployment model is a hard(mandatory) requirement for your organization, raise it directly with the ReleaseOwl team to confirm current options.

This depends entirely on the organization's release scenarios, such as standard releases, hotfixes, and parallel landscape flows, so the right number of pipelines is best worked out with the ReleaseOwl team during Discovery and implementation sessions rather than assumed in advance.

Please refer to the ReleaseOwl documentation for detailed information on features, configurations, and supported capabilities.