If a policy isn’t enforced by the technology, it’s not a policy, it’s a guideline.
This is exactly what SPGA does, it uses technology to enforce your governance standards. While most purchase SPGA for its ease of site provisioning, while maintaining those governance standards, what about activities that occur post-site creation (i.e. end user change requests)?
The single most important post-site creation item that comes to mind for most organizations, would be adding users to groups. If you care about governance in your environment, you probably have some policies regarding who gets access to what. If you allow your users access to maintain their own groups, how is the technology enforcing those policies? It’s probably not, so they are just guidelines.
Here are a few top benefits of using SPGA to manage your group membership:
- Your SharePoint environment will be more secure than ever because you can now easily ensure that you’ll never have unauthorized access to a site
- For the first time ever, you can use approval workflows to approve security modifications.
- You can finally answer the previously unanswerable question, “how did user X get access to the HR site?”
Besides the governance process mentioned above, I’ll give you two more benefits of using SPGA to add users to groups. First, how many times are your SharePoint administrators called because a site owner has removed their own access to the site trying to modify permissions? I’ve been there, I know it happens. Managing permissions in SharePoint can be complicated to those that don’t manage permissions frequently.
This leads to my second point, if you use SPGA to add users to groups, you don’t even need to teach your site owners about managing permissions. They can be completely clueless about the real process, they only need to know how to fill out a SharePoint form.
The detailed steps in this article will be a bit lengthy, but for you existing SPGA users, this is a step by step process you can follow to unlock more of the features you already have access to. For potential SPGA customers, I hope you can see the value in not just the site provisioning features, but in automating post-site creation activities (i.e. change requests) such as this one.
Some things to note before beginning:
- You should add an approval workflow (out of the box or SharePoint Designer) to the request to approve all permission changes.
- Some of the initial setup covers items that would be useful for many purposes within SPGA and not just specific to this particular Request Profile.
- SPGA is extremely flexible so this is just one method of accomplishing this, there are other ways to accomplish this or fine tune it further to meet your specific needs.
- If you are new to SPGA, and it seems complicated, we provide consulting services with your purchase to get all of your Request Profiles setup with you to ensure a successful launch of SPGA in your environment.
We will use this list to log information, which we will use in various Request Profiles. For the purpose of this article, I am using the default Title field and added fields for URL and Department. In the image below you can see my list with a few entries.
Step 2 – Modify your existing site Request Profiles to log information to the previously created Site Collections list.
I will modify my “New Extranet Site” Request Profile which creates new ExCM extranet sites.
The two activities you will need to add are Open List, and Add List Item.
In your open list activity, use the function button to select Context.Site as the site, and in List Name use the edit button to enter the name of the list you created – mine is “SiteCollections.” Add a variable name of your choosing to the List output.
Next, in the “Add List Item” activity, use the function button to select the variable from the previous step (Properties.outList).
For List Item Title, use the function button to select the Site Title from the input field (this is the field the user completes when filling out the form to request their new site). The List Data field is a text field and you need to use this format; COLUMNNAME:DATA. In my case the column is called URL and I want to use my site url that is created within SPGA - $Properties.SiteUrl achieves this. So the first line would be URL:$Properties.SiteUrl. Do the same for department – which is another input field we present to the user. So – Department:$Inputs.Department. It should look similar to the screenshot below.
The end result of all you have done above in Step 2 is to write a new list item to the SiteCollections list every time a new site collection is provisioned by one of your new site collection Request Profiles in SPGA.
Step 3 – Create your request profile to add users to groups.
I created a new Request Profile called “Add Users to Groups.”
The next series of screenshots will show you the input fields that need to be created, along with the field types and selections I made. (Note: the Input fields are what the end user will select from on the request form).
The Department field is an SPGA List Lookup type field. It is a lookup on the SiteCollections list we created in the first step. It pulls in the Department field that gets logged at site creation.
The field with the display name of “Select your site” is a field I named “SPSite” (SPGA field names cannot have spaces) and is also a lookup to the SiteCollections list. This time it is cascading from the department choice the user makes. It allows the user to select the site they want to add users to, by selecting the site name, but providing the site URL as the value to use in the execution of the request.
Next we need to allow the user to select the group they would like to add a user(s) to. In all my site Request Profiles I use standard SharePoint group names to keep it simple.
The last Input field is the AddUsers field, which allows the user to select the users from AD (or ExCM forms based users) that they would like to add to the group.
Note the granularity you have when configuring this Input field type. You can specify one or more directory scopes (the Principal Source multi-select check box field in the screen shot above), and whether or not you will allow AD Groups and/or Distribution Lists to be selected.
Make sure you have your WebAppUrl variable set to the web application for which the sites exist. If you have multiple web apps you can handle that as an input field as well and pull from your SiteCollections list.
The last piece is adding the appropriate activities. The first four are standard “open” activities to get to the group requested. The final activity adds the user(s) to the group.
You can see in the image above my options for each of the activities.
Open Web Application – opens the web application specified in Execution Properties
Open Site Collection – uses the above web app plus the site selected from your input fields
Open Site – opens the root site of the site collection selected in above step
Open Group – opens the group based on the user selection in the form, on the site selected by user
Add Group Membership – uses the input field for to know which users to add to the selected group
Step 4 – Sit back and enjoy the fact that your security governance policies are now in fact policies, and not just guidelines.
To take it a step further I would copy the “Make Request” link for the new “Add Users” Request Profile, and modify your existing site Request Profiles to automatically add the link to every site created. This way when the user is on their site, they have a link right there to go ahead and get to the request form to request adding new users to a group.
Here are some more screen shots for you to get an idea about what the end-user experience will be when requesting a change using the new Add User Request Profile:
This one shows the team site the user is on with the added links in the right column to allow them quick access to the link the request form.
When that link is clicked they are presented with the form.
You can see here that once they select their department (Human Resources) they are presented with the HR sites in the Site Collections list.
Once that’s done, they select the group to add them to, and the users to add to that group.
Clicking Finish would put it in the queue for processing. If you have approvals turned on, as you should in this scenario, the approver would now be notified, and once approved, the users added to the group.
You can also review the history of the Add User Request Profile usage by going to the Requests list that tracks all of the requests submitted through SPGA.
The image below shows the record logged into the Requests list. Notice all of the fields that were selected and completed as well as the group the users were added to and the users that were added. Also the created by shows who submitted the request. You can see who approved and review the workflow process by clicking the Workflows option on the item.