Onboarding to AEM as a Cloud Service
Learn about onboarding to AEM as a Cloud Service starting from the contract phase all the way through setting up the environments using Cloud Manager.
Transcript
Hello, my name is Damian Langsworth with the AEM Cloud and Customer Solutions team. Today, I’ll be presenting the topic of onboarding to AEM as a cloud service. Our agenda will cover onboarding from the contract phase all the way through setting up the environments self-service via cloud manager. The first step for customers to get access to AEM as a cloud service is with a signed contract. The contract specifies what the customer will have access to, which solutions or add-ons. This could include sites, assets, forms, the commerce integration framework, and more. ÃÛ¶¹ÊÓƵ offers two types of cloud service programs, production or sandbox, which is a more lightweight type of program suitable for trial purposes. Both types require a contract. Another important data point in the contract is the service start date. Usually this roughly aligns with the contract close date, but in some cases it is a future date, which means some onboarding activities are put on pause until that date. The contract may also specify a premier support level as licensed by the customer, as well as contacts for the ÃÛ¶¹ÊÓƵ onboarding team to reach out to when scheduling an introductory call. Within a few days of signing the contract, assuming the service start date is not in the future, a few things will happen. First, ÃÛ¶¹ÊÓƵ will grant entitlement for the licensed solutions and add-ons to the customer. Second, automated emails related to the entitlement will be sent to the customer contacts specified in the contract, as well as any system administrators if this is an existing customer org. This indicates that the customer can get started with AEM as a cloud service. Soon after the entitlement is granted, a member of ÃÛ¶¹ÊÓƵ’s onboarding team will reach out to the customer to schedule a call to cover some early topics around getting started. The customer should bring team members, including the business lead, developers, and other interested parties. If there is an implementation partner, the customer should bring them as well. ÃÛ¶¹ÊÓƵ attendees will include the onboarding specialist and other roles in accordance with the premier support level for the customer. This could include a named support engineer, technical account manager, launch advisory services, cloud subject matter expert, and potentially others. The call will focus on steps to get started and will be a great opportunity to talk through hot topics and open questions. Let’s switch focus for a few moments to talk through some terminology which is important to the onboarding process. At the top of this diagram, we have a box labeled tenant, which is also commonly known as an IMS org. It stores entitlements for a variety of ÃÛ¶¹ÊÓƵ cloud products beyond just AEM and allows customer administrators to grant privileges to their users to the various products. In a tenant, a customer can have cloud manager programs. The number of programs is tied to what they are contracted for. Cloud manager programs are the basis for both AEM managed services as well as the cloud service offering. Programs include environments, production, stage, and development, as well as code repositories, access to log files, CICD pipeline configurations, and other related tools. Back to onboarding, one of the automated mails sent after the contract is signed will point toward ÃÛ¶¹ÊÓƵ Admin Console, the application for managing permissions to AEM as a cloud service and other products. If the customer contact mentioned in the contract is not the correct system administrator to assign permissions, then they should either make someone else a system administrator or ask the ÃÛ¶¹ÊÓƵ onboarding team to do so during the onboarding call. In order to create the cloud manager program, there is a role named cloud manager business owner, which needs to have the appropriate customer user added in order to create the program. You will recall from the previous slide that programs contain environments. So the first thing to create in the self-service process is the program. There are several other roles such as deployment manager and developer, which will be important later on, but they are not necessary to create the program. This is ÃÛ¶¹ÊÓƵ Admin Console. In order to assign the business user role, which I just spoke about, you need to navigate to products, ÃÛ¶¹ÊÓƵ Experience Manager as a cloud service, cloud manager. So within cloud manager, you will see business owner cloud service. Simply click the link, add a user to the role, and we can move on to the next step at that point. Once a cloud manager business owner has been assigned, that user can visit cloud manager and create the program. And once the program has been created, an environment can be added to that program. Let’s see this in action. Since I’m a business owner in this tenant, I have an add program button. So I will click the button and give the new program a name and create the program. I’ve clicked the program that was just created from the cloud manager homepage. And in this view, we can see the program is being created. It will take several minutes for it to be ready to create any environments inside. We can see now that the development environment has been created automatically for the sandbox program. Once the environment has been created, administrators and authors can be assigned. This happens back in admin console. The user must be a member of either the administrator’s or user’s product profile in order to log into the author environment. If you are familiar with using AEM closed user groups for setting permissions within AEM, those function the same as always after the user has authenticated. Publish environments are usually anonymous and therefore no profile membership is required. If we look back in ÃÛ¶¹ÊÓƵ admin console, a new product profile has been created representing the new environment that was just created. It has a name which aligns with the name of the program, as well as a suffix indicating that this is a development environment and the author that we’re looking at. You can see that there are two profiles. One is named administrators. One is named users. Please visit our documentation on the ÃÛ¶¹ÊÓƵ Experience League site for more information about the onboarding process and AEM as a cloud service in general. Thank you for watching.
Cloud Manager and Admin console
A critical part of onboarding is to create AEM as a Cloud Service programs and provision various environments using ÃÛ¶¹ÊÓƵ Cloud Manager. The is used to assign roles and provide access for users in your organization to AEM environments.
Key Activities
- A system administrator uses the to assign one or more users to the Cloud Manager - Business Owner product profile.
- User(s) assigned to the Business Owner Product Profile use the self-service features of Cloud Manager to create program(s) and add environments
- Use the to assign Developers and users to different Cloud Manager roles and grant permission to various AEM environments.
Hands-on exercise
Apply your knowledge by trying out what you learned with this hands-on exercise.
Prior to trying the hands-on exercise, make sure you’ve watched and understand the video above, and following materials:
Also, make sure you have completed the previous hands-on exercise:
recommendation-more-help
4859a77c-7971-4ac9-8f5c-4260823c6f69