It’s been a while, but I think, this post will have some valuable information for you if you work a lot with Nintex Workflow.
In Nintex you can create new sites, apply templates, define the URL, etc. but one thing that was always missing is the ability to create SharePoint groups for the newly created sites. Since Nintex Workflow 2010 offers UDAs (User Defined Actions), I thought it would come in quite handy to wrap this in a UDA. And here it is. This post explains the concept of the UDA, what is actually happening within the UDA and how to use the UDA. I provided both, the NWF file as well as the UDA file for you.
Scenario
The IT department of Company X created a self-service portal where users can go to a SharePoint list, fill in some details and after an approval they get their own Team Site. Then they would have to go into the Site Settings and modify the permissions, break the inheritance, comply with the SharePoint group naming convention, etc. A lot of things to do, if you ask me. But why not automate this process? Let the workflow do all the work for you and automatically set up a group with Full Control, one with Contribute and one with Read permissions. On top of that you can easily enforce a common naming convention for SharePoint Groups, something like “Sitename_Grouprole”.
How does it work?
Let us have a look at the workflow within the UDA, which is quite simple.
We are using two web services, which come out of the box with SharePoint. The UserGroup (http://[SITEURL]/_vti_bin/usergroup.asmx) and the Permissions (http://[SITEURL]/_vti_bin/permissions.asmx) web service. The first one lets us create a SharePoint group by using the AddGroup method. The second one lets us set the permissions within the site by using the AddPermission method.
Within the UDA we create the group first (NOTE: The group will actually be created on a site collection level). In case there was an error, the UDA skips the set permissions web service and spits out an error message, which you can handle appropriately within your workflow. If the group creation was successful, the next step is to set the permissions. The UDA allows you to specify whether the group gets read, contribute or full control. Depending on the parameter passed to the UDA, it will then set the correct permission mask.
That’s it. Simple, isn’t it? And all that with no code and just using web services which SharePoint provides already.
How do I use the UDA?
Drop the UDA into your workflow, right after the “Create site” action. The UDA requires a few input parameters:
- Group Name – provide the name for the group to be created
- Group Owner – specify who owns the group in the format DOMAIN\USERID
- Group Permission Level – provide one of the following values:
- Read
- Contribute
- Full Control
- Site Name – the name of the site you just created
- Site URL – the URL of the site you just created. Be sure you provide it in the following format: http://[ServerURL]/site
In the event of an error within the UDA (connection issues, group already exists, etc.) there are 2 output parameters:
- Error Message – The message returned by the web service that errored
- Error Occurrence – Indicates that an error occurred within the UDA
Using the output parameters will help you to handle the exception appropriately within your workflow.
The web services in the UDA use a workflow constant (Site Collection Level) called “SharePoint Web Service Account” of the type credential. You will have to create this constant before you can use the UDA as it currently stands. The account will have to be able to read web services across the site collection, so read only access to all sites for this account will be fine.
Alternatively you can modify the UDA in a way that the credentials are passed to the UDA as part of the input parameters.
Resources
Download UDA and NWF files – Create SharePoint Group
SPBasePermissions Enumeration
GetPermissionCollection – Converting Permission Mask to Roles
SharePoint Permissions Methods