Determine the access model components for your Cloudlets
This task is very specific to your organization and to the set of Cloudlets you use. Depending on your organization’s needs, you may need to add new groups and roles for your Cloudlets, or just use your existing access model structure.
When considering how to structure your access model, ask yourself questions like these:
|Will you need multiple groups to support your Cloudlets?||We're using this Cloudlet with two separate properties. I want two separate groups for Cloudlets because we don’t want users that work on the one property to access Cloudlet policies on the other property.|
|Can you use any of your existing groups for your Cloudlets implementation?||I'm going to create a subgroup for my Cloudlet. Why? I already have a group for the department that will use this Cloudlet most. In the subgroup, I'll limit access to only the people working directly with the Cloudlet.|
|How are you breaking down the Cloudlets-related tasks across your organization?||We want to use the same process we use
for our other site changes: one person makes the changes, while another deploys the
To keep things consistent, I want to have distinct editor and administrative roles for our Cloudlets.
|Can you use any of your existing roles for your Cloudlets implementation?||The team already has view, edit, and administrative roles set up, so I’ll just add the appropriate Cloudlet permissions to those roles.|
|If you have multiple Cloudlets, what levels of access do you want to provide for your users?||All Cloudlets users should be able to view policies for all Cloudlets. Only users working directly with a Cloudlet should have editorial and administrative permissions. Given this, I'll set up multiple roles specifically for our Cloudlets.|