Through the Adobe@Adobe program our company is customer zero. We deploy unreleased versions of our software within our enterprise so we can provide real world testing before releasing our software to the public.
Late in 2014, our team, along with the Creative Cloud for enterprise team, embarked on a program to deliver Creative Cloud for our employees using not the ubiquitous AdobeID but rather a Federated ID – our employee’s network ID – similar to how any other large organization would.
The following article is our lessons learned along with tips to help customers make the most of their experiences deploying Creative Cloud for enterprise.
Purpose of this Package
This Creative Cloud for enterprise Customer Success Package is intended to provide you with a head start, as you get ready to deploy Creative Cloud. This package includes samples of various pieces of content we used in Adobe’s own internal deployment of Creative Cloud within our own enterprise. It also includes lessons learned and feedback from employees along the way.
You’ll find a sample project timeline, sample communications to employees, IT help documents and links to the technical best practices guide we followed. We hope by providing this content we can help you shorten the time to deliver Creative Cloud to your employees by reusing this content.
Note: The content in this package was created to support a Creative Cloud deployment with a single sign-on (SSO) provider like Okta. If you are planning a different type of deployment such as a serialized, Adobe ID or an Adobe managed Enterprise ID some of this content may still be relevant.
Thinking about SSO, Culture & Communication
Employees of large organizations generally have many systems they need to access to perform their job. This has only increased in recent years with the move to a hybrid enterprise where many SaaS services are accessed in the cloud.
The promise of SSO for employees is that the employee only need log in to their desktop computers once. Then the rest of the day they have access to all the sites and services they need – all without re-entering their password each time. The promise of SSO for the IT Admin is that they can provision software and services for employees en masse thereby speeding up employee on-boarding, etc.
People & Process Impact
Delivering a new way for your employees to login to a service they depend on can be a challenge. Ideally you would like to personally stop by each employee’s desk and walk him or her through what is changing to ensure they are prepared. In a small office this may be feasible but if you have hundreds or thousands of users spread across the globe this quickly becomes impractical.
A key success factor for this project was in preparing our employees for change. Change is never easy. Delivering clear messages to your employees can help ensure they handle the change without overwhelming your IT Support team.
In the Communications section you’ll see how we tackled the creation of these messages. In the Support section you’ll see how we leveraged support documents from Adobe to help us think about what our employees might need assistance with.
In general, Adobe’s internal employee Creative Cloud for enterprise project was part of a larger program called Adobe@Adobe in which we deploy/implement software within our company before it is publicly released. With this project in particular, we were concurrently building the Creative Cloud for enterprise product and planning the internal deployment. This real-world testing provides a great way to identify and remediate software bugs.
Adobe’s Enterprise Deployment Planning Guide is available to help you identify activities during your deployment planning. This guide is not intended to replace the planning guide and anyone planning a deployment should be familiar with its content before leveraging this example.
Our deployment project at Adobe was very simple. We expect customers to have various groups of users within their company that are entitled to some but not all Creative Cloud products and services. In addition, we expect customers to have contingent workers who also need access to Creative Cloud.
For Adobe’s internal deployment we granted all regular, full-time, not temporary, Adobe employees full access to CCE. This greatly simplified deployment. We did not create packages to deploy to users; instead we directed users to leverage the self-service feature of Creative Cloud allowing them to download applications themselves.
Several weeks prior to the full company wide deployment, we ran a pilot with 100 users from across Adobe. It is important that you pick the right 100 users. Be sure to choose a representative cross section of your employees – both technical and non-technical users.
We were moving to a new federated ID service provider, Okta. This pilot helped us fine-tune both the SSO experience and the Adobe Creative Cloud desktop application experience for our enterprise use.
Our project focused on preparing users for the change and getting our internal IT support team ready to take support calls.
These roles are not an exhaustive list of participants but rather an outline of the types of roles we leveraged.
This section is where someone from your IT team starts his or her work. Where you begin creating groups, loading users, setting up a trust, architecting and configuring the SSO experience for your end users.
Single Sign-On is like having all the locks in your house re-keyed so they use the same key for different doors. Single Sign-On in reality is more complex since there are different ways to enable that single key. Within Adobe we leverage the Single Sign-On provider Okta to manage that sign on experience for our employees. As a customer the same Okta service is available to you. However if you already use an identity provider you can use your identity provider.
Setting up SSO
Our Adobe IT team leveraged the documentation located on the Adobe Enterprise Help Hub. The content below is from the Configure Single Sign-On article. See that article for more details on how to setup and configure SSO as well as the SSO FAQ.
When organizations configure and enable Single Sign-On (SSO), users in that organization are able to use their corporate credentials to access Adobe software. This enables users to use a single credential to access Adobe desktop apps, services, and mobile apps.
The Adobe Enterprise Dashboard offers a method for enterprise users to authenticate using their existing corporate identity. Adobe Federated IDs enable integration with a Single Sign-On (SSO) identity management system. Single Sign-On is enabled using SAML, an industry-standard protocol which, connects enterprise identity management systems to cloud service providers like Adobe.
SSO can securely exchange authentication information between two parties: the service provider (Adobe) and your Identity Provider (IdP). The service provider sends a request to your IdP, which attempts to authenticate the user. If authentication is successful, the IdP sends a response message to sign the user in.
To successfully set up SSO for Adobe software, IT Admins need the following:
- An understanding of SAML 2.0
- An Identity Provider (IdP) that supports SAML 2.0, and at a minimum must have:
o IDP Certificate
o IDP Login URL
o IDP Binding: HTTP-POST or HTTP-Redirect
o Assertion consumer service URL
- Access to your DNS configuration for the domain claim process
If you do not have IDP information, review this article and contact your IdP for the required information.
Technical Lessons Learned
For the technical work involved we only ran into one issue during deployment. And even then it was a very minor issue. We started with a group of 100 employees. This pilot group took a pre-release version of the Creative Cloud desktop software and helped us shape the experience.
We exported the group of pilot users from our Active Directory using the template that customers can find in the Adobe Enterprise Dashboard. When we deployed Creative Cloud to our pilot users one of our users reported that he was unable to login. After investigation we found that his email address had a space in front in the .CSV upload file. That space caused his record to be skipped in the upload process. One of the nice features of our Enterprise Dashboard is that during an upload of users you’ll get a report of the users that were skipped. In addition the entire upload is not derailed if it encounters a problem.
The only other issue we ran into was one of data formatting. Our IT Admin needed to spend time to convert the country name to two-letter country code. When our Active Directory team exported our employee data the country was spelled out, not in the two-letter code. The export from Active Directory illustrated something that may be common in other company directories – countries were not all named the same. For instance, for the UK we had United Kingdom, Great Britain, England, etc. It didn’t take them long to use find and replace in the spreadsheet and make the changes – but it was an unexpected activity.
Communication & Support
Communicating with our users was challenging because timing of the deployment. On one hand, it coordinated perfectly with the annual global Sales conference where sales teams learn about new products and services. As a result, the product team and IT were able to demonstrate Creative Cloud for enterprise to them in a production environment.
On the other hand, the deployment was also the week prior to Adobe’s year-end shutdown. As such we faced grabbing the attention of a workforce preparing for and anticipating a holiday break.
Overall, the launch was effective. The entire sales organization experienced Creative Cloud for enterprise.
Our internal communications reflected Adobe’s unique situation as an Enterprise customer because we changed the model for assigning accounts to employees. Historically employees received a Creative Cloud account based on their work needs. Adobe made the decision to provide every employee with a Creative Cloud for enterprise account meaning we contacted every Adobe employee to advise them of their new account and ask for their help testing this new service.
Our rollout was also complicated somewhat by the simultaneous introduction of a new corporate-wide authentication process which was an important aspect of the users message.
Finally, we eliminated standard awareness communications leading up to the launch due to timing. In the month leading up to the internal launch we were competing with fiscal year-end earnings release and the Thanksgiving holiday in the US. We decided that the return on communications during this period was too low to justify the action.
We have included both our overall CCE Comms Plan as well as sample internal communications used in our roll out. Both files are included, along with the support documents below, as part of the zip file attached to this article.
In looking back at the documentation that Adobe provides it was helpful to review the Switching from Adobe ID to Enterprise ID article (included in zip file below). It helped us to frame our communication and support around the fact that employees were getting a new account. All your Creative Cloud files and synced fonts in Typekit will not be accessible.
We created a number of support documents to help employees understand what is changing and how to get help without contacting our IT Support team.
Since the majority of our employees already had Creative Cloud accounts we wanted to ensure they understood how to move content between their current account and the new Enterprise account. Please see the document in the zip file titled, IT Support Document – CCE Working with multiple CC accounts for our example.
In addition, we created a Frequently Asked Questions article for use within our internal IT Support knowledge base that could help users understand what is changing. Please see the document in the zip file titled, IT Support Document – CCE FAQ.
Finally, rounding out the IT Support Documents included in the zip file is the IT Support Document – CCE Getting Started guide. It is a basic document that helps employees get up to speed with Creative Cloud and points them to the other documents we created.
Best Practices & Lessons Learned
You can never be too prepared, especially in terms of support. People across your company likely possess different levels of technical expertise. To ensure messaging and support is most valuable, technical insiders (project core members) as well as people not involved with the project should review all documents and flows. We ended up reviewing and testing our own work, which could have been more effective had we employed “real” employees.
We held several trainings with our internal IT Service Desk in addition to several communications to our Service Desk team. The emails we sent to our Service Desk team helped to give them a heads up that this project was coming and offered several times for the team to attend a training session. We also had a liaison from our IT Service Desk that was part of the weekly project team meetings. This helped our internal IT support team be better prepared for any user calls.
Conducting a pilot with a small number of users definitely helped us fine-tune the experience for our employees. However, ensure that the pilot experience and target experience is as close as possible. In our case, we were still building the new Creative Cloud Desktop app so our pilot users needed to perform a number of steps that were not needed in the final roll out; This lead to more than expected negative feedback for the pilot group.
We created a feedback form that captured feedback from our employees. This was a great way to get input into our project. One piece of feedback we received during our pilot was that signing out of Creative Cloud desktop app was not clear. We realized that for non-technical employees or employees that are unfamiliar with the Creative Cloud Desktop app signing out of it requires you to go to either the menu bar (mac) or task bar (windows) and execute a set of steps to sign out. Walking through all aspects of the experience with non-technical users would have been beneficial.