Hi Gerrit,

This depends on your information architecture.  I personally think it's best to put your workflows and forms where it makes sense in the site.  It's where the data is going to reside most of the time.  e.g. if you had an HR section in your intranet and travel request information is kept there, then put the workflow there too, not in a separate "workflow" site.

Also if you kept all your workflows/forms in the single site then your task lists etc are going to fill up faster than if they were spread out across multiple sites.

Some things you'd need to be aware of by not keeping all workflow/forms in the single site/collection are:

• Your users might have to go to multiple sites to see all their pending tasks (you can only aggregating tasks at the farm level if you have the Enterprise edition)
• Reusable templates can only be shared across a site collection so if you wanted to share/maintain the same template across multiple site collections, there are some manual steps you'd need to perform to keep them in sync.

I thought I might harness the opinion of some other gurus for comment.  What do you guys think Dan Stoll​, Vadim Tabakman​ and Andrew Glasser​?

Cheers,

Chris

Hi Gerrit,

I agree with Chris to not necessarily look at keeping all workflows and forms in a single working site, but allow them to spread across the intranet and reside where the users will "work". For example, if you have a department for finance, and they have a library of working contracts that have not been executed. When the document is ready to be executed and become final, they need to get approvals. Instead of moving the document to a separate site collection and then starting the approval workflow, a workflow can begin where the document has been worked on all along. This architecture will also support your governance needs around permissions. Imagine having to move this document to another site that doesn't have the same permissions and it is now visible to unexpecting visitors.

Do you have any reservations to this alternative approach? Let us know what questions you have.

Thanks both.  Just another question, if the forms and workflows are spread across the site collections, how do you keep track of what Nintex Forms & Workflows you have, particularly when you want to do some workflow history maintenance as part of your monthly routine?

Also, would you spread the lists with forms and workflows throughout the different site collections or would you dedicate a subsite (call it eForms) per site collection for this?

You can use the NWAdmin commands to find all of the Workflows using the FindWorkflows command. See here for details NWAdmin Operations - Nintex Workflow 2013

There is also an alternative using PowerShell Finding all of the workflows in your farm using PowerShell

I think I've seen a discussion on finding Forms, but I can't recall the method.

For the last question, it could make sense to structure the forms to a subsite, So if you are creating a site reserved for a functional area then this would work. You would have a list per form.

But i'm curious what forms you are planning to build? Would they be forms that are for group A and then another 8 forms for group B, then another set for Group C? Could those forms reside in those group's working sites? It is not typical to create a site collection or subsite just for forms, but I can definitely see a case for it.

Thanks Andrew, much appreciated.  I indeed was thinking about a set of forms for each group, eg. HR would have a number of forms, so also IT, and so forth.

Sounds great. Let us know if you have any further questions on this topic or if you feel like it has been answered for now, go ahead and mark it so. I'll try to watch out for any future questions as well. It sounds like you have a great opportunity to make Nintex a real business solution.