In this blog post, I would like to explain various entities in SAP Cloud ALM and explain how they are connected
You have things that are Project specifics such as scopes and Requirements and things that are project independent such as Release and Release versions.
Something with a purpose with dates, teams, scope, requirements, features, and user stories. It can be used for “Continuous Implementation” which means running perpetually
A series of timelines were created for deployment purposes. Multiple projects can refer to the same Release but one Project can have just one Release
Release contains Release versions. Release versions have start and end dates and can be assigned to Requirements, User Stories, and Features
A Collection of Business Processes that need to be handled together. You create a Scope and then first assign Solution Scenarios such as SAP S4HC with a particular content version and then pick processes from those Solution scenarios
A series of steps following BPMN notation explaining a business functionality, typically used in Fit to Standard workshops. You can associate Requirements, User Stories , and Project tasks to a process
A list of typical responsibilities. You get the initial list from the SAP Activate methodology but you can add your own list of roles. you can assign multiple persons to the same role in a Project and use roles for task assignments if you work in a ‘pull’ fashion and have self-empowered teams.
Teams currently exist within a Project. A team is made of multiple roles and each role contains multiple persons.
a special Team that is delivered by default. This is the only team that contains the Project lead and this team can not be deleted. You can change the name of this team
An activity that needs to be performed. This is created by the Project team and can be edited or deleted
Content delivered by SAP whose description can not be edited. If not required, this can be set to a state “Obsolete” and then deleted
A business need that typically needs to be processed for approval and is later decomposed into smaller items such as Project tasks and user stories
A functional detail of Requirement. User stories can also be directly created from the process and may depict pre-approved requirements or change requests coming from Production incidents that do not need approval
A child of Template task. Project task or user story. Used to distribute work between team members
The entity that is required to document change records and move functionality to production. One Requirement can have multiple features but a feature can have only one Requirement. Multiple user stories can belong to a Feature
Different systems that are used by Projects and Releases
An aggregation dimension for Requirements, user stories, and Features. Currently, a controlled list that comes from SAP Activate methodology
Community-driven classification that can be attached to Requirements, Tasks, User stories, and defects
a vehicle for testing that can be attached to a Requirement or a user story
A record indicating a functionality not working properly
As we publish more and more blog posts, it’s easy to get last. Please visit the Master Blog post and bookmark it.
To understand an end-to-end picture, please visit
Expert Portal for Implementation and stay connected