Another month, another set of new features in Nintex Workflow for Office 365 and another blog post telling you about another set of new features in Nintex Workflow for Office 365 (search engine ranking is going to LOVE that opening. If only I could find one more way of getting ‘new features in Nintex Workflow for Office 365’ into the opening paragraph. Oh well, I’ll think on).
To be correct though, the release this month is of new Nintex Live actions for Office 365, rather than actions for the native app. Regardless, they are as follows:
- Update XML
- Query XML
- Start Workflow
The one I really want to concentrate on with this post is the new action that will enable you to start another workflow in Office 365.
Why is this a good thing?
You’ve been able to do this for a while in the on premise version of Nintex Workflow and there are a number of reasons why you might make use of it:
- For large process modelling
- For flexibility
- For Best Practice
- For Cross-Tenant Processes
Large Process Modelling – When designing and managing large workflows, it is often a good idea to avoid creating one monster process (you know, the sort that would need you to print it on 17 sheets of A3 in order to see the design as a whole). Better to build your process up using a number of smaller workflows. I suggest having a master control process, with smaller sub-processes hanging underneath and representing each stage.
Flexibility – In our scenario above, what happens if you want to change a section of your process as the business requirement evolves? Or add a few new steps. Better to have the flexibility to change just 1 small process that forms part of a whole, rather than having to change one monster.
This rings true for smaller processes you might has as well however. Want to add a new stage? Why not create another small workflow and start it from your master process.
Best Practice – All of the things I’ve mentioned above could be considered best practice. Best practice is important as your environment grows, is used more and become business critical to your organisation. There is a great series of articles from colleague Patrick Hosch on best practice for workflow, you’ll find it here: Patrick Hosch Blog – Nintex Best Practice Series
Cross-Tenant Processes – “Wow, really?!” Well yes, why not. The action allows you to specify the ‘Destination Site URL’ and the account under which the process will be started. So why not start a workflow on another O365 tenant?
So why not start a workflow on another O365 tenant?
No reason why you shouldn’t.
Think about the likelihood of larger organisations having different tenants delivering different business benefits to different groups of people. Now think about the possibilities being able to start cross-tenant processes offers.What does it looks like?
Here it is. You’ll find it as part of the ‘Office 365 Lists and Libraries Actions’ pack, along with the two new XML actions. Once in the toolbox, you will see it under the ‘Integration’ heading.How do I configure it?
So here is a blow-by-blow description of how to configure it. It really isn’t that hard and if you’ve used other actions in the Nintex for Office 365 app then you’ll already be pretty comfortable with this I’m sure. But just in case…Input Fields Destination Site URL
‘The URL of the site where the workflow you want to start lives .’
OK so far. As you will see all over Nintex products, this field can be derived from text, list lookups, workflow variables or a combination of all three should you wish. Here I am using a workflow variable which will have a text value that looks something like https://YOURTENANATNAME.sharepoint.comWorkflow Type
‘The type of workflow you want to start.’
Two options here; Site Workflow and List Workflow. There are implications as to which one you choose. If you select the ‘Site Workflow’ option you don’t need to specify the list item you start the workflow on (obviously?). See the ‘Item ID’ field for details.Workflow Name
‘The name of the workflow you want to start.’
Err, explained I guess.Item ID
‘Specify the item or document on which you would like to start the workflow.’
Pretty clear this one. As mentioned in the ‘Workflow Type’ field configuration, you only need to specify an ID if the workflow you are starting is of type ‘List Workflow’. Think about how this could be used. An item might be created in another list as part of an earlier step in the process. The ‘Start Workflow’ action can then be used to kick off a workflow on that item.
But why wouldn’t you just set up the workflow on the destination list or library to start when a new item is created?
Good question. Perhaps between the item being created and the workflow starting on it there are other steps that need to be completed, steps such as:
- Asking someone for input on the item
- Asking for someone to review, then approve or decline the item
- Waiting for another process to update the item with information from a Nintex Form perhaps
In these examples, ‘Start when items are created’ and ‘Start when items are modified’ are not appropriate. It’s great that we can choose exactly when we want it to fire.
As such, I don’t need to specify the item ID. If I was starting a list or library workflow, I could specify the ID using a value stored in a variable for example. The value in this variable could have been written as part of a create item action earlier in the process. Nice!
‘The URL of the site we are currently on.’
As with the ‘Destination Site URL’ input box, I’ve used a variable to store this information to make my life easier. The field will have something similar to https://YOURTENANATNAME.sharepoint.comUsername
‘The username of the person that will be starting the workflow.’
Again, I have stored this information in a variable so that I can use it across the workflow context as a whole. 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.’
I chose another variable here. You could do a lookup perhaps. Whatever suits.Output Fields Workflow start successful
‘Specify a Yes/No workflow variable that will store whether or not the workflow started successfully. Returns “Yes” if the workflow was successfully started.’
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 process actually having started, you may want an error branch so you can stop problems from happening later down the line.
There’s also a nifty feature that, when you select ‘Create New Variable’, opens up a configuration panel on the left, changes focus to the variable name box AND selects the correct variable type so you can’t make mistakes like data type mismatched. Thanks Nintex!
‘Returns the workflow instance ID of the process you just started.’
Really useful if you want to update the current item with the unique workflow instance that you just started. Or perhaps you want to add it to the workflow history by way of a lightweight audit trail. Or whatever else you can think of.
This is all I have to say on the start workflow action for now, but I think you probably get that I’m pretty excited about it and for good reason. When you combine this ability with ‘State Machine’ and ‘Run If ‘actions, and if you’re properly labelling them too, we can start to build some really powerful and understandable processes.
If I find the time I may write a follow-up post for the other two actions in this month’s release, as the XML actions work really well together and are worth looking at further.