What email address or phone number would you like to use to sign in to Docs.com?
If you already have an account that you use with Office or other Microsoft services, enter it here.
Or sign in with:
Signing in allows you to download and like content, which the author will be aware of.
Embed code for: IntraActive Workspaces Administration Guide
Select a size
1. Introduction 2
2. Overview 2
2.1. Configuration site 2
2.2. Administration site 4
3. Configuration tasks 5
3.1. Manage wizards 5
3.2. Define Workspaces permission group 10
3.3. Manage features, to be used in template definitions 11
3.4. Manage pipeline actions 12
3.5. Manage email templates 16
3.6. Manage workspace template definition 18
This document contains guides to the various administration and configuration tasks of workspaces. It takes offset in a basic understanding of the workspaces functionality, but does not require deep insight into the inner workings of the service layer and actions.
The document is structured into sections, each of which describes a configuration area, such as defining a wizard, or defining a new template definition. The document is not meant to be read from end to end, but to act as a reference to look up, when a specific task is to be accomplished.
The audience of this document is IT administrators or Workspace owners.
This section contains a brief overview over the sites and lists, containing configuration elements.
The configuration site is often the ”Workspaces portal”, where the workspace directory exists. Configurations on this site is related to the daily operation of Workspaces, and this is where the template definitions, permissions and overall business rules are defined.
The table below contaisn a brief description of the main lists used by IntraActictive Workspaces. For more elaboreate description of each administration task, please refer to the “Confuguration tasks” section.
Contains the various email templates used, e.g. the template for the “Site created” email, sent to the primary contact when a new site is created.
This list contains the features that can be selected in the template definition.
A feature that needs to be added to new/existing sites from a specific template, needs to be defined here first.
Contains a full list of all pipeline actions, available for configuring template definitions.
This does not contain the actual action files, but only a title and internal title, used for reference. The actual files exists on the Administration site, where additional configuration about each action can be done.
Each step (screen) in the wizards are defined here, and refered to in the actual wizard definition.
Contains the wizard definitions. This can e.g. be “Create project site”. Each wizard refer to a number of steps, from the Wizard steps list. Each step can be used in multiple wizards.
This list contains all the templates, which can be used for creating workspaces. This list refer to many of the other configuration lists, as a template defintion is a combinations of many elements, such as pipeline actions and features.
This list contains all the workspaces created, along with meta data. All the specific sites, groups and other instances of workspace types live here in this master list.
Workspaces Directory Drafts
When a user request the creation of a new workspace, an item is created here. Only when the workspace is picked up by the Workspaces service, will it move to the “Workspace Directory” list.
The administration site, is where the more persistent configurations are applied, related to the backed and service layer of workspaces. These are often one-off settings, done during installation, but can be changes, e.g. when new actions are applied.
The table below describes the mail lists and libraries used on the administration site.
Contains the files containing the pipeline action.
Contains any configuration for each pipeline action. Configurations can exist for an action in general, or for a specific template.
This section contains a guide to the the various configuration tasks possible with Workspaces. Some tasks can be a combination of other subtasks, e.g. “Define template defintion”. In this case, the guide refers toeach relevant section.
Wizards are used for guiding the user through the process of site creation, but can be used for anything related to data capture using a SharePoint lists. Basically the Wizard will act on top of a specific list and in a number of steps defined in the definition ask the user to enter values to the item. It is entirely possible to create a wizard for capturing information related to other processes within an organisation.
Defining a wizards is done in two main steps; defining the individual wizard steps and defining the overall wizards itself.
Define Wizard step
The first thing you need to do, when creating a wizard, is adding some steps. A wizard step represents a “view” of the general wizard, each consisting of a number of fields of a content type.
The wizard steps are defined in the list “Wizard Step” on the configuration site.
Figure 1 – Example of Wizard step definition
Each step item, requires the following information:
The title of the step is only used to get an overview on the “wizard step” list itself.
The internal name of the step, is used when referring from the overall “Wizard” definition.
An optional description, used only for administration, and not displayed to users of the wizard.
A reference to the internal fieldname, of the defined content type (defined on the general wizard) that is displayed on this step. The order they are defined in, is the order they are displayed on the wizard.
The format is the following:
The Wizard, is what ties the steps together and defines the overall wizard. Each wizard can be openened by the url (relative to the configuration site):
Figure 2 - Example of Wizard definition
Each Wizard item, contains the following information:
The title, used on the list of wizard and as headline for the Wizard itself.
This is only used internally by the wizard functionality. No spaces allowed.
A desription of the wizard. This is not displayed to the user.
The name of the content type, this wizard is based on. The individual wizard steps must include field from this content type only. When the user has entered the form, an item of this content type is created in the list specified below.
The list in which to save the item in. When the user has completed the wizard, an item is created in this list, of the content type specified above.
The content type needs to be added to the list as a prerequisite.
A URL of a page to redirect to when the wizard is complete. For workspaces site creation, a page is used that informs the user of the process, and that it will take a few minutes before the site is ready.
A list of steps, referred by internal name. List them in the order they must appear in the Wizard. Below is an example of the format.
The example below, shows a Wizard defined with 6 separate steps.
Figure 3 - Example of Wizard as the end users sees it
Define Workspaces permission group
It is recommended to create specific groups for each template, so that the groups permisson levels can be changed for a specific template alone. Changing the permission level on the configuration site, will propagate to the created sites as well. The necessary groups are created on the configuration site.
Groups names need to be prefixed with “Workspace”, in order to be selectable when defining a template.
The permission level the groups are defined with on the configuration site, is the one used on the created workspace. It is recommended to use custom permission levels, in case they need to change.
It is recommended to prefix the permission level with “Workspace” as well, but not a requirement.
Manage features, to be used in template definitions
When defining a workspace template, it is possible to select which features that needs to be activated. These features are activated on creation but also during maintenance, in case more features are added at a later point.
The features are defined in the list “Features”.
Figure 4 - Example of feature definition
Name of the feature. This is not used for the logic, so it is merely for administration reference.
Feature ID (GUID), that uniquely defines the feature.
Site or Web.
Manage pipeline actions
All available pipeline actions needs to be represented in at least two lists.
The “Automation Profiles” list on the Admin site
The “Action Configurations” list on the Admin site (Optional)
The “Pipeline Actions” list in the Configuration site
Automation Profiles – Admin site
When a new pipeline action is created, it needs to be uploaded to this list on the Admin site. This list does only contain the file, and no additional information regarding the action is defined here.
Figure 5 - Pipeline action nuget file
Action Configurations - Admin site
Some actions can be configured to perform different operations and the Action configurations list is where these configurations live.
Figure 6 - Example of action configuration
The action confuguration requires these fields:
Name of the file on the “Automation profiles” list - full name without extension.
This is where the actual configuration values are instered. The format of this can vary from action to action.
The Scope defines which template definition this specific configuration applies to.
In case different configurations of the specific action, are used for different template, an item is created for each action/template pair.
The internal name of the template definition is used. In case a configuration is to be used for all template, the value “All” can be used.
Pipeline Actions – Configuration site
Finally the pipeline action must be represented on this list on the configuration site, in order to be selectable when managing template definitions.
Figure 7 - Example of pipeline action definition
A pipeline action item, requires the following fields:
User friendly name of the action, used when defining the template.
A reference to the name of the action, uplaoded to the Automation Profile list (admin site) – without extension.
The sort order indicates how the action should be presented, when a template is defined. Optimally, the sort order indicates the suggested order execution of the actions, making it easier to select and order actions, when defining a template.
For backward compatability
Manage email templates
Emails are used for several purposes in the process of workspace creation and maintenance. The most obvious example is the mail sent when a workspace is created. The email templates are managed in the “EmailTemplates” list on the config site.
Figure 8 - Example of email template
A email template consists of the fields listed in the table below.
Each field can contain the following “tokens”, that will be replaced before send out.
[SITENAME] – is replaced with the title of the site created
[RECIPIENT] – is replaced with the displayname of the receiver of the email
[SITEURL] – is replaced with the Url of the site created
[GREETINGFROM] – is replaced with a greeting configurable in the Action Configuration
Name of the email template, used by the pipeline action.
The subject line for the email
HTML value of the email content.
One way of creating the mail body, is to author an email in outlook, and then save it as html. Open the saved file in note pad, and copy the html.
Manage workspace template definition
The workspace template definitions, is what ties many of the other configuration lists together.
Each template definition consists of a combination of a content type to include the fields specific for this template, permissions and an amount of actions that is run when a new site is created, and which to run when maintained. The templates are defined on the list “Workspace Definitions”.
When creating a new item , or editing an existing, the wizard functionality will take control and guide you through the necessary steps.
Each step will be explained here below, seperately.
Step 1 – Base information
Figure 9 - Workspaces definition wizard step 1
On the first screen, the following information needs to be added.
The name of the template definition. This will be the name, the users see, e.g. when they creates new sites.
A general description of the template, visible to end users.
And internal title, used for internal references. It is recommened to avoid space and special characters.
The order of which the template is to appear, in the template selector drop down for end users – when they create new sites.
Step 2 – Site information
Figure 10 - Workspaces definition wizard step 2
The second step is about defining the site information.
Applied if the template can be used for root sites (Site collection)
Defines which of the standard SharePoint site templates, that provides the foundation of this site template.
Defines the path used for these sites. For SharePoint online, only /sites or /teams are available.
Defines the default site language.
Defines who should be site collection administrator
Step 3 – Associations
Figure 11 - Workspaces definition wizard step 3
The third step is about Associations and to select the content type which defined the information attached to this types of sites.
Associated content type
Defines the content type used for the sites created from this template. The content type must include the necessary fields related to the template.
The choices in this drop down, is based on the content types added to the “Workspace directory” list – which inherits from the content type “Workspace info”
Defines the features to acticate on the site, after creation.
The features available for selection, is the featured defined on the list “Features“.
Link to a js script ressournce that should be included on the site (all pages). This can be used to add general functionality to the site, or to display e.g. site information on the front page.
Step 4 – Security
Figure 12 - Workspaces definition wizard step 4
The fourth step is about defining the site security groups and levels.
The groups that is added to the site, is added here. The groups will get the permission level they have on the configuration site.
Please refer to section 3.2 for explanation about how to make groups and permissions levels available for selection.
Defines the associated owner group
SharePoint operated with three main groups, also known as “associated groups”. While a lot of groups can be added to a site, the associated groups needs to be available on a site, for SharePoints logic to work.
Defines the associated members group
Defines the associated visitor group
Step 5 – Actions
Figure 13 - Workspaces definition wizard step 5
The fifth step is about defining the actions that should run when creating a site, and the actions that runs in maintenance. The order of actions can be difficult to know, however if best practice is kept by developers, the actions are provided in the order they should run.
Defining the actions that should run when the site is created. Please notice that the order is important, and the action on top will be the first to run, and one at the bottom of this list will be the last to run.
Defining the actions that should run in maintenance. These actions will run several times for each sites, and is typically actions that keeps data in syn.
Step 6 – Approval
Figure 14 - Workspaces definition wizard step 6
The sixth step is about defining wether site creation requires approval, and to define the message displayed on site creation.
Defines whether sites require approval before they are created.
A html formatted message, that is displayed when the site is being created.
It takes a couple of minutes before the site is created, so this message can be used to explain that the user will receive an email when the site is created.
Define who can create which types of sites
In some situations the different workspace templates are relevant for different audiences. E.g. it might be relevant for everyone to create project sites, but only manager should be able to create department sites.
Configuring who should be able to create which types of workspaces, is simply defined by the item permissions on the “Workspace Definitions” list. Everyone with read access to an item, can create a workspace from this template.
Workspaces - Administration Guide 14cond step is about defining the site information.
The fifth step is about defining the actions that should run when creating a sit