available_templates.cfgfile is an XML configuration file that lists all of the workflow templates that are available for use on the TeamSite server. For each workflow, this file indicates the name of workflow, the location of the workflow template file, and the conditions under which the workflow is available.
By default, the
available_templates.cfg file is located in:
available_templates.cfg is edited and contains non-ASCII text, it must be saved in UTF-8 encoding.
available_templates element is the container element for the file. This element contains the following attribute:
require_workarea— specify whether (
true) or not (
false) workflow templates selection screen will include a branch/workarea chooser if workarea context is not present. Most of the out of the box workflow template examples require this to be enabled (
require_workarea="true") to work properly. Default value is
available_templates element is the
Author Submit Workflow"
template_file element has the following attributes:
name— specify the title of the workflow, for example:
name="Author Submit Workflow"
active— indicate whether (
yes) or not (
no) the workflow template is enabled. Default value is
- path — specify the path where the template file resides. Template files must reside in one of the following locations:
The value you specify is relative to the
/local/config/wft directory, so if the template file resided in the following absolute path:
then you would specify the value:
Specifying Template Access
You can configure access to each template listed in the
available_templates.cfg file by using any combination of the following categories:
The categories can be combined using boolean terms such as AND, OR, and NOT to include and exclude those that meet the inclusion or exclusion criteria you configure. Template access is configured within the allowed element, which is a subelement of template_file:
template_file element is the
allowed element, where you can configure user access by matching workflow commands with user roles:
Workflow commands are specified by the
command element. The
command element specifies the user-activity that starts the corresponding workflow. For example, the following configuration:
specifies that the associated workflow is started when performing a Submit and that it cannot be invoked by other means.
The valid command values that you can associate with a workflow are:
assign(assign button or menu item)
new_TFO_job(new job, in TeamSite FrontOffice)
tt_data(saving FormsPublisher data records)
tt_deletedcr(deleting FormsPublisher data records in ContentCenter Standard only)
all(all possible values from this list)
tt_data command is valid in ContentCenter Standard and can be configured in ContentCenter Professional; see the User Interface Customization Guide. The
tt_deletedcr command is only valid when users are using the ContentCenter Standard interface; in ContentCenter Professional, this command is not valid and data records are treated like any other assets.
Access based on TeamSite roles is specified by the
name attribute. For example, the following configuration:
specifies that if the user is logged in as an Author.
Access based on user groups is specified by the group element:
Access based on individual user name is specified by the user element:
Access based on TeamSite branch is specified by the
Combining Access Categories
Pairings of individual or multiple access elements can be included or excluded using the
notelements within the
allowedelement. You can use boolean logic to create combinations of categories that can either have access to a specific template, or be excluded from it.
In the following example:
<template_file name="Author Submit" path="default/author_submit.wft">
the following individuals have access to the Author Submit workflow:
- Those who are authorized to perform
- Those who have the
- Those who are members of the
- Those who have the
adminrole, with the exception of the user
If no access category is specified, it is assumed that category has full access to the workflow template.
Regular Expression Support
You can use regular expressions when specifying
branch element constraints within
available_templates.cfg to search for a specified pattern and specify what to do when matching patterns are found. Using regular expressions allows a greater level of flexibility when adding items.
For example, if you want only the users in the three
administration_1 branches (
a3) to access a workflow template, you can set the following constraint:
If a new branch called
a4 is added to
/default/main/administrator_1 you could manually update the
available_templates.cfg file to allow access for users in the new branch by adding the
branch element to the existing ones:
Or you could modify the
available templates.cfg file to use the following regular expression and, thus, automate the constraints placed on the
This regular expression allows users from any branch under
/deault/main/administrator_1 to have access to the template.
When using regular expressions, the path-separators (“
/”) are all translated to “
/” in both the pattern and the string to match against before attempting the match.
In the following example:
any branch path that includes the string
foo will be matched. Here the following examples match:
In the next example:
any branch path that begins with the value-string will be matched. Here the following example matches:
while this one does not:
The following examples are all treated as identical on both Windows and UNIX.
<branch name="^/default/main/foo" include="yes"/>
<branch name="^\default\main\foo" include="yes"/>
<branch name="^\\default\\main\\foo" include="yes"/>
<branch name="^/default\main\\foo" include="yes"/>