I am actually surprised I could not find any previous posts regarding this subject, so here I go
We often use Nintex to create site collections in collaboration environments and often customers try minimizing custom development. For this reason the current "save site as template" functionality is actually very useful. When new site collections are creating through the UI it is also possible to import the created template to start your site collection from.
In Nintex it would therefore also be awesome if there would be any way to refer to non-default templates to start the site collection from.
Is anyone aware of such a solution? Possibilities I am thinking of are
- Creating the template in code and import it as a farm solution (but I actually want to avoid this)
- Triggering a powershell script for the creation of the site collection that refers to a certain library where the solution is stored
- Nothing easier?
Anyone experience with this?
Hi Glenda, Sites that have been saved using the Save as site template are stored in your solution gallery and will appear on the list of available templates when using the Create Site Collection action in your workflow. If you are not seeing this please make sure you have saved the template in the same site collection you are running the workflow from.
Yes the option for that template should be showing in your configuration screen should the workflow be running in the same site collection for the site that host the saved template.
Let us know if you have any issues.. Or a screenshot always helps.
One word: awesome.
I am actually really surprised that I did not find out that this is possible. It broadens the workflow possiblities . Tested it, works like a charm!
A limitation could possibly be that you cannot activate wsp's that contain features you have not available in the site collection you are using for running the workflow. But this is merely something I guess one should take into account when designing the templates or structure.
I have gone the powershell route for a couple of solutions, but using Nintex Workflow to manage a list of "site provisioning requests" - then the powershell script runs as a scheduled task on a server to watch that list, and provision sites as required.
The main issues we needed to go the powershell route for were to cover the various problems with SharePoint templates - e.g. no subsites, publishing breaks, default column values break, and disposition settings break... Going the powershell route means we have freedom to set all those things up as required, and do other things, such as buildin permissions sets, content types, putting webparts in place, building lists, views, etc.
I guess the attraction of the powershell approach versus a utility webservice, or extending Nintex Workflow through the API is that powershell doesn't need to be re-deployed if you're making a change, or fixing a bug.
Hi Jonathan, thanks for your input.
I agree that PowerShell could be a more recommended way of working in most scenario's.
Although depening on the needs of the sites that are set up using the template taking the low level save-site-as-template OOTB features route is also a great choice. Especially if you want to allow customers to make changes theirselves (without any experts I would not recommend using PowerShell ).
In the template views can be created, pages can be edited containing some predefined webparts (even custom ones), Nintex WF could do initial security set up of the permissions of your site collection in case they are default/not default. Content Types could be a problem, but depends what the structure is and how they are used within the SharePoint environment/organisation. When using templates and Content Types are an important part, the Content Type Hub could also be of great help.