Ever Wanted to Create Something Beautiful?

Ever woken up feeling rested, thrown back the curtains to reveal a glorious sunny day and thought to yourself; “I want to create something truly beautiful today”?

No, me either*. So instead let’s take a really quick look at the Nintex Workflow for Office 365 ‘Office 365 create site’ action and how to configure it.

So here’s the action:

Nintex Workflow 'Office 365 Create Site' action Icon

“Will I have issues configuring it?” I here you say.

Well no, probably not. And if you do you’ll soon know about it because Nintex Workflow for Office 365 will present you with the error message “Some parameters failed the validation check” (just to let you know that you’ve not quite cracked it) and then will promptly ‘Suspend’ the workflow so as not to cause any further problems.

So just in case you do run into difficulties, here is how we configure it broken down field-by-field.

Input Fields
Title

‘The title of the site.’

No surprises there. But note that, as you will see all over Nintex products, this title can be derived from text, list lookups, workflow variables or a combination of all three should you wish. Here I am using a list lookup to a ‘New Project Request’ list (the token is ‌‍‌‍{Current Item:ProjectName}‍‌‍‌) which has a custom Nintex Form attached to it – just in case you were wondering.

Description

‘The description of the site.’

This is similar to the ‘Title’ field above. Again I’m using the {Current Item:ProjectName}‍‌ token which is a lookup to my lovely project request list.

Inherit permissions

‘Specify whether to inherit permissions from the parent site. If not inhering permissions from the parent site, please specify Site owner(s).’

Well you have a yes/no choice here. But again, as with the ‘Title’ and ‘Description’ fields, you can get to this boolean logic in as many ways as you can imagine.

Site Owner

‘Specify the site owners when not inheriting permissions. To specify multiple owners use ‘;’ to separate the user name (e.g. user1; user2).’

Pretty clear this one. You can add more than one and these names could be stored in a variable or in a list field.

Parent site URL

‘The URL of the parent site where the site will be created.’

I’ve used the ‌‍{Workflow Context:Current site URL}‍‌ token for my parent site URL.

URL name

‘The name to display in the site URL.’

Here is a gotchya. What we need here is a name and nothing more. So in my example I’m using a combination of text and a list lookup token to create a unique url – ‌PMO00{Current Item:ID}‍‌. In the configuration for the field above I used the CurrentSiteURL token which ends in a /. If you’re not too sure, perhaps write the key values to the history list ahead of this action so you can be sure you’ve got the right data. Just a suggestion.

Language

‘Specify the language for the site.’

This is just a lookup, so look up the language you want and we’re good to go.

Template

‘Specify the site template to use.’

Again this is a drop down so choose your poison.

SharePoint Online URL

‘The SharePoint Online domain URL we authenticate against; e.g. http://targetdomain.sharepoint.com.’

As with many of the field configuration I have described, this can be configured using text or any number of lookup configurations. If your’e configuring this action to run in a workflow on the root site for example, you could use our good friend the  ‌‍{Workflow Context:Current site URL}‍‌ token.

Username

‘Specify a username with permissions to create the site.’

Remember this will have to be constructed with the tenant name and onmicrosoft.com after the ampersand. See the screenshot for details

Password

‘Specify the password for the above username.’

Again, choose your preference as to how this is delivered. Lookup, variable..

Use top link bar from the parent site

‘Specify whether this site will have its own top link bar or use the one from its parent.’

A presentational option that has no bearing on whether this action will run successfully of not as the input is boolean. Just there so you can cut down on some of the post-workflow SharePoint administration.

Output Fields
Site creation successful

‘Specify a Yes/No workflow variable that will store whether or not the creation of the site was successful. Returns “Yes” if the site was successfully created.’

This can be really handy if you want to have an outcome logic gate – i.e. if a later stage in your workflow depends on that site actually existing, you may want an error branch so you can stop problems from happening later down the line.

Site URL

‘Specify a workflow variable to store the URL of the new site.’

I use this kind of outcome variable all the time. On the project request process I’m basing this article on, I use this to update a project register with the newly approved project including a link to the project site which will be used to manage it. You could also use the link in a notification email or to effect later actions in the process.

I hope you found this useful. I did.

Hang on – if you found it useful, and you didn’t know how to configure it before, and you do now, and you use it as part of a workflow, and everyone loves that workflow, and everyone loving your workflow makes your day…

…then maybe I did create something beautiful!

Thanks for indulging me

*NOTE: I live in London, England and so the chances of me being rested AND London being sunny on the same day are very remote.
Not using Nintex Workflow for Office 365 yet? Want to find out more? Try going here

One Comment

  1. Cedric October 15, 2014 at 11:26 am #

    Very useful indeed thanks! Now that we created a site we would need to add users to a SharePoint group. I cannot seem to find the action on SharePoint Online. Please help 😉

Leave a Reply