Lesson 5 of 5
Getting started
7 min
Listen to this lesson
Provisioning Cloud ALM takes little clicking and several decisions, two of which cannot be undone. This lesson walks through the request, the first setup steps and the roles each delivery team member needs.
- Check accessAn S-user with the Edit Cloud Data authorization for the right customer number
- RequestSAP for Me provisioning dashboard: start provisioning for Cloud ALM
- ChooseData center region, subdomain and Identity Authentication tenant
- ActivateThe requester becomes the Main IT Contact and first administrator
- Set upOnboard users, assign roles, set up Landscape Management
The request
Start from the Cloud ALM page on the SAP Support Portal or directly in the SAP for Me provisioning dashboard, where Cloud ALM appears under systems to be provisioned. The person who submits the request needs an S-user with the Edit Cloud Data authorization and becomes the Main IT Contact, with the authorizations for initial setup. SAP advises that only someone who will actually do the setup should submit it. If Cloud ALM already shows a provisioning status, someone in your company has requested it; find that tenant before you do anything else, because the entitlement is one per customer number.
The permanent choices
- Region: the data center that hosts the tenant. Pick one close to your main SAP systems. A tenant cannot be moved later without being rebuilt.
- Subdomain: part of the tenant URL, unique, typically containing your company name and ending in
-cloudalm. It cannot be changed after provisioning. - Identity Authentication tenant: reuse the productive SAP Cloud Identity Services tenant your other SAP cloud services trust, or let SAP create one.
| Decision | Can it change later? | Contoso's choice |
|---|---|---|
| Region (data center) | No, not without rebuilding the tenant | A US data center close to the S/4HANA systems |
| Subdomain | No, fixed at provisioning | Company name plus -cloudalm |
| Identity Authentication tenant | Possible, but switching disrupts users | Reuse the productive tenant Contoso's other SAP cloud services trust |
First setup: users, roles, landscape
SAP describes the required setup in three steps. Users are onboarded in Identity Authentication (or come through your corporate identity provider via it), roles are assigned in Cloud ALM's User Management app, and systems and services are set up in Landscape Management. A user needs to exist in both Identity Authentication and Cloud ALM before they can sign in. Decide early whether to use a corporate identity provider, because switching later can disrupt existing users.
- Onboard usersCreate users in Identity Authentication, or bring them in through the corporate identity provider
- Assign rolesGive each user a Cloud ALM role in the User Management app
- Set up the landscapeRegister quality and production systems in Landscape Management
- Sign inUsers that exist in both Identity Authentication and Cloud ALM can now work
Roles for delivery teams
| Cloud ALM role | Allows (paraphrased) | Typical Contoso owner |
|---|---|---|
| Global Administrator | Manage all Cloud ALM objects and settings | Two named Cloud ALM administrators |
| User Administrator | Create users and assign roles | PMO or security admin |
| Project Administrator / Project Lead | Manage projects, scope, requirements, features, test cases and defects | Grace (PMO lead), Priya (test lead) |
| Project Member | Work with tasks, requirements, test cases and defects | Functional consultants and test authors |
| Tester | View and execute test cases, create and edit defects | Maria and other key users in UAT |
| Project Viewer | Read-only access to projects | Executives and auditors |
| Change Manager / Deployment Manager | Approve features for production / deploy transports | Release manager, Basis |
Common Cloud ALM roles. Check SAP's role list in the Cloud ALM help for exact authorizations and combination rules.
Projects also have an access level (public, restricted or private) and project teams with Activate-style project roles, which you use to route tasks. Map every person on the program to a role before you invite anyone.
Keep roles narrow. Business testers rarely need more than the Tester role, and giving them Project Member rights "to be safe" lets them edit test cases mid-cycle, which undermines the evidence. Review the user list at each phase gate and remove people who have left the program; Cloud ALM data often includes design decisions and defect details that should not stay open to former team members.
What would you do?
Contoso's IT director wants the tenant requested today and asks a junior analyst with the right S-user authorization to submit it, "since it's just a form." What is the risk?
- Request Cloud ALM in SAP for Me with an S-user that has Edit Cloud Data; the requester becomes the Main IT Contact.
- Region and subdomain are permanent; reuse your productive Identity Authentication tenant where possible.
- Required setup: onboard users, assign roles in User Management, set up Landscape Management.
- Name at least two administrators and give every tester the Tester role before testing starts.
Check your understanding · not graded
Lesson check
1. Which authorization does the requesting S-user need?
2. Which provisioning choice cannot be changed later?
3. In which app are Cloud ALM roles assigned to users?
4. Which role lets a key user run test cases and raise defects?