Defining a Process Workflow in Altium NEXUS Server

Parent page: Creating & Managing Processes

A foundation stone of the collaborative design environment in Altium NEXUS is the support for Workflows, that guide a company's designers through typical, everyday design processes such as requesting new managed parts, performing design reviews, and creating new managed projects.

Each Workflow that is used to implement a particular design process is created as part of a Process Definition. It can therefore be referred to as that process's underlying Workflow, or simply a Process Workflow. New processes can be created, and existing processes edited, using the dedicated Process Workflow Editor. This document takes a look at accessing the editor, and working with it to craft the process workflow required.

Accessing the Process Workflow Editor

Processes are created and managed from the Processes area (Admin – Processes) of the NEXUS Server's browser interface.

To access the Process Workflow Editor, make active the tab for the process theme in which you want to create your new process – Part Requests, Project Activities, or Project Creations – then click the button at the top-right of the page.

Accessing the Process Workflow Editor. Ensuring the desired process theme is made active before access will ensure the new process definition will be set to the right theme type.

The Process Workflow Editor provides a canvas with which to craft your desired workflow in diagrammatic fashion. The main area of the editor is where you create the workflow diagram, while the Properties pane on the right-hand side presents properties related to the currently selected diagram element.

When no placed element is selected in the diagram, the Properties pane will reflect the Name and Type (which process theme it belongs to) of the process definition. Give the process a meaningful name, as this will appear in the NEXUS Server's browser interface, as well as the applicable access points of the Altium NEXUS GUI – for designers to be able to initiate an instance of the process (provided it is activated for use).

The Workflow Diagram

A process workflow diagram is built using various elements, available from the palette at the top of the area.

A workflow diagram is built using elements from the available palette.

The following table lists all possible diagram elements:

Icon	Type	Description
	Connection	this element provides for interconnection between event-point elements in the workflow. Its shape can be modified graphically and while by default its Name is left blank, this can be useful for indicating/describing the various paths emanating from a branch element in a flow.
	Start	the starting point for the workflow. The Name is prefilled by default depending on the theme – Submit Request (Part Requests), Start Activity (Project Activities), Create Project (Project Creations). This can be changed as required. For information on the default fields added to the associated form for this element, see Built-in Fields and Default Fields. For the Project Activities process theme, this element offers support for a second Type – Start Release. This is used for a workflow in which a released project is to be published to an integrated PLM instance, all as part of the Altium NEXUS Project Releaser. For more information on switching the type for this element, see Changing the Type for a Workflow Element.
	Event	this element can be used to acquire the result of an action within an integrated PLM instance (providing output of OK or FAIL, along with a message and log). To do so, set the Type for the theme accordingly – PLM Part Completed (Part Requests), PLM Publish Completed (Project Activities), PLM Initialise Completed (Project Creations). By default the Name is prefilled with the Type entry, but can be changed as required. This element can also be used to send and receive notifications to a 3rd party system using the NEXUS Server EDS (requires access to Altium NEXUS Server SDK). Set the Type to Send or Receive accordingly (you would need both Send and Receive events defined as part of the workflow). Notifications consist of a unique identifier Code and message. Note that the Code must be the same for both Send and Receive events. For Project Activities, the Type for this element can also be set to Related Tasks Completed. This is for use when comments have been added and assigned as tasks to specific people – associated with the activity for a project itself. It means that the process workflow for the activity cannot be completed until all related tasks – the assigned comments – have been resolved as well.
	End	the end-point for the workflow, or branch of that workflow. The Name for the element can be set to either Completed, Rejected, or Cancelled.
	Task	this element represents a task to be undertaken – something that one or more users are required to perform. In a review-based Project Activity workflow, this could be giving feedback as part of a review. In a Part Request workflow, this could be to work on a particular component that has been requested, or perhaps only its symbol, or footprint. Each task provides, or acquires data from the user, through a dedicated Form – built with all the fields, variables and information required to achieve the task's purpose. For more information, see Building a Form. Aside from the standard User Task (defined as needed through a form), each process theme supports one or more additional types – Create Part in PLM (Part Requests), Collect Project Data and Publish to PLM (Project Activities), Initialise in PLM (Project Creations). In each case, the Name is set by default to the task's type, but can be changed as required. Additional settings must be defined for each type, and differ between the types accordingly, such as Assignee and Task Ownership. For a PLM-related type task, it is used to acquire the result of the action with the PLM instance (providing output of OK or FAIL, along with a message and (for Project Activities and Project Creations themes) properties). For more information on switching the type for this element, see Changing the Type for a Workflow Element.
	Branch	this element provides for branching of the workflow, depending on acquired results from a previous point in the flow (e.g. acquisition of user choice, or decision). By default the Name is left blank.
	Comment	this element allows you to comment your workflow, typically adding a comment at each point in the flow, detailing what should happen at that point. By default the Name is left blank.

Placing Workflow Elements

To place an element from the palette:

1. Click on the element's entry on the palette. An instance of the element will appear, highlighted in blue, floating on the cursor.
2. Position the element at the required location on the workflow canvas and click (or right-click) to effect placement. As you move the element around the canvas, alignment guides will appear in relation to the horizontal and vertical centers of existing placed elements.
3. To cancel placement, press Esc.

Example placement of elements onto the workflow canvas (Start, End and a User Task). Notice the dynamic alignment guides that provide help when placing.

Connecting Workflow Elements

To connect two workflow elements:

1. Click on the entry on the palette.
2. Position the cursor over the first (source) element to be connected and click.
3. Move the cursor to see a connection line begin to extend from the element. Position the cursor over the second (target) element to be connected and click.

Connection between elements should flow from left-to-right, since this is the logical flow. You will be prevented from selecting a target element to which connection is deemed invalid (e.g. trying to connect an End element to a Start element). In such a case the target element will appear with a red fill, and the end of the connection line will remain with a 'prohibited' icon ( ).

4. Continue placing further connections, or right-click, or press Esc to exit.

Example connection of elements in a workflow.

Moving Workflow Elements

To move an element, click and drag it to the desired new location. If the element is connected to one or more other elements through connections, those connections will be kept, and the connection line path(s) modified accordingly. Use the dynamic alignment guides that appear to help with positioning.

Example movement of one, then multiple placed elements. Note that connections, unless part of the selection, will be modified to keep elements connected accordingly.

Modifying a Connection

When you hover the cursor over a connection, various editing controls, or 'handles' become available. These allow the following modifications to a connection to be made graphically:

• Click and drag the handle to move the connection in the vertical plane only.
• Click and drag the handle to move the connection in the horizontal plane only.
• Move the cursor along the connection, the handle will follow the cursor. Click and drag this handle to create a new vertex point for the connection.
• Click and drag the handle to move the starting point for the connection. You must drag this point onto another existing element.
• Click and drag the handle to move the end point for the connection. You must drag this point onto another existing element.

An invalid drop point when moving the start or end point of a connection is highlighted by the element having a red fill (and the appearance of the icon at the end of the connection). This could happen, for example, if you attempt to move the start point for the connection to the same element to which that connection's end point is already attached. In this case, move the end point first, then the start point.

Example modification of existing connections, using the various editing handles that appear when hovering over a connection.

Modifying Element Properties

As mentioned earlier, the right-hand side of the Process Workflow Editor provides a Properties pane, presenting the properties for the currently selected workflow element. For some elements, such as Connection, Branch, End and Comment, their only editable property is their Name. For others, such as Start and Task, you have settings that can be defined, as well as an associated Form that can be crafted as required. Remember also that properties for a workflow element can change depending on the process theme under which the process is being defined (and the type chosen for an element, where multiple types are supported for that element).

Properties pane presenting default properties for the Start workflow element (when defining a process within the Project Activities theme, and setting the element's Type to Start Activity). Hover over the image to show the default properties when the Task element (configured as a User Task) is selected.

Make changes to properties of a selected workflow element as required through the Properties pane. For an element that can have a Form defined, you will need to either create the form (click the button in the Form section of the pane) or edit it (click the entry in the Form section of the pane). For more information, see Building a Form.

Changing the Type for a Workflow Element

The following process themes have workflow elements that support multiple types:

• Part Requests theme:
  • Task – supporting the types: User Task, Change State, Create Part in PLM.
  • Event – supporting the types: Send, Receive, Notify User, PLM Part Completed.
• Project Activities theme:
  • Start – supporting the types: Start Activity, Start Release.
  • Task – supporting the types: User Task, Change State, Collect Project Data, Publish to PLM.
  • Event – supporting the types: Send, Receive, Notify User, PLM Publish Completed, Related Tasks Completed.
• Project Creations theme:
  • Task – supporting the types: User Task, Create Project, Change State, Initialise in PLM.
  • Event – supporting the types: Send, Receive, Notify User, PLM Initialise Completed.

After placing an element onto the workflow diagram canvas, you can change between its available types using the menu associated with the button, which appears inside of/next to the element once it is selected.

Cycling through the types supported for Start, Task and Event elements, when defining the workflow for a process that is part of the Project Activities process theme.

Task Assignment

How a task within the workflow gets assigned, depends on the settings defined for Assignee, Except, and Task ownership:

• Assignee – could be a single user for your NEXUS Server, multiple users, or a specific role (grouping of users). Variables can be used here too, for example $Initiator (the person who started the process instance), or $Review Coordinator (the user chosen to be the Review Coordinator in a previous task).

• Except – who is not allowed to work on the task, even if they are part of the assignee scope. For example the requestor of a part should not approve their own part request! Another example might be using the $Rework executed by variable in the Except field for the Verify rework task of a Milestone Review process, to prevent the user who performed the preceding task (Rework) from being able to verify their own work.
• Task ownership – determines who can act on a task, in relation to the user(s) specified in the Assignee field. The following options are available:
  • One of assigned users – if there is only a single user in the Assignee field, the initial task of working on the request is assigned directly to that user. If there are multiple assignees, all users see the task in their tasklist, and one of those users assigns the task to them self.
  • All assigned users – all assignees receive the task.

The image below shows the assignment settings for a Part Request process definition. The Assignee is defined to be the admins for the NEXUS Server (members of the Administrators role). Task ownership is set to One of assigned users, meaning that one of those administrative users must take on the request.

Which user initially receives the task of working on a new part request, depends on how the settings for Assignee, Except, and Task ownership have been defined, for the initial user task – in the underlying workflow for the applicable process definition. The image above shows the settings for the default New Part Request process definition.

Configuring Data Visibility for a Standard User

You have the ability to configure parametric data visible to the standard user on the Data tab for a process workflow – when viewing the progress of an active instance of that process. When editing the workflow for a process, and with no element selected, the data that can be presented on the Data tab is listed in the Properties pane. Click the control to access its related form (<ProcessName> Data).

From this form, you have the ability to determine whether or not a parameter is made visible on the Data tab. By default, a parameter is visible ( ). Click this control to make it non-visible ( ). In addition, you can control the order in which data is presented. As you hover over a parameter entry, the control appears to its left. Click and hold this, then drag the parameter to a new position.

The following image shows the relationship between the form and what an administrative and standard (non-administrative) user sees on the Data tab for the process. In this example, Description and Datasheets parameters are hidden from the standard user.

Deleting a Workflow Element

To delete a workflow element, select it, then use the Delete keyboard shortcut. To delete multiple elements, click and drag a selection box around them, or use Ctrl+click to individually build selection, then use the Delete shortcut.

Building a Form

Two workflow elements – Start and Task – involve asking a user to do something. This could be a request for initialization information (project name and type, initial data set for review, requested part number, manufacturer and datasheets) or some other task along the flow that requires additional user input in some way (review decision, additional data, comments, finished part for a request, and so on). These two elements can both be thought of as being task-oriented.

To present the necessary fields and variables to facilitate such user interaction, a Form is created. In some cases, a Form already exists with built-in fields that cannot be removed, while in others, a Form is available, and has default fields, but these can be modified to suit. And in other cases still, a Form does not exist, and you therefore have relatively free range to craft a Form as simple or as complex as required for your company's needs.

The following list shows all variants of these two tasks that use/require a Form:

• Start (Part Requests theme) – existing Form with default fields. These can be edited or removed, and default values defined where applicable. Additional fields can be added as required.
• Start of type Start Activity (Project Activities theme) – existing Form with built-in field. This cannot be removed. Additional fields can be added as required.
• Start (Project Creations theme) – existing Form with built-in fields. These cannot be removed. Default values can be defined where applicable. Additional fields can be added as required.
• Task of type User Task (all process themes) – no existing Form. Create as needed.
• Task of type Collect Project Data (Project Activities theme only) – existing Form with built-in field. This cannot be removed. Additional fields can be added as required.
• Task of type Create Project (Project Creations theme) – existing Form with built-in fields. These cannot be removed. Default values can be defined where applicable. Additional fields can be added as required.

The User Form Editor

A Form is crafted using the User Form Editor. For an element that can have a Form defined, you will need to either create the form if it does not yet exist (select the element in the workflow and click the button in the Form section of the Properties pane) or edit it if it does (select the element in the workflow and click the entry in the Form section of the Properties pane).

A Form is built by adding fields – representing named variables – of required types, and by setting flags (where applicable) of how those fields are to be used – essentially crafting an interface with which to pass information to, and solicit information from, the targeted user(s) who will perform the task.

When the form is saved – click the button at the bottom of the Form – a summary of all fields define thereon, along with their variable types, is presented back on the Properties pane for the selected workflow element.

Example of the User Form Editor populated with the Form for the Provide review feedback User Task (part of the Milestone Review process definition, within the Project Activities theme). Notice that the Properties pane provides a convenient summary listing of all fields defined on the Form, along with their types.

The following sections take a look at the mechanics of the User Form Editor, including its support for variables and fields, associated flags for each field/variable, working within a Form, and built-in/default fields and variables.

Variables and Fields

Things to be aware of in respect to variables and fields:

• A Variable is a named data element, tracked as part of the workflow for a process.
• A Field is the representation of a variable, in the context of a particular user Form within the workflow for a process.
• There is no dedicated functionality to manage variables for a process:
  • A user-defined variable is added to the process when the administrator adds this for the first time to a Form within the workflow for that process.
  • A user-defined variable is removed from the process when it is removed from all of the Forms used within the workflow of that process.
• The majority of variables will be defined by the administrator when crafting Forms within the workflow for a process definition. There are some predefined variables, built-in to a process definition for particular workflow elements. These can be used elsewhere on other user-defined Forms, but remain defined for the process, even if removed from all Forms within a workflow.
• There is only one variable definition in the process, meaning that wherever this variable is edited (any Form) changes are automatically reflected on all other Forms used within that workflow, and on which the variable is used.
• Variable names are case insensitive (i.e. you cannot have two variables that differ only by case).

Supported Variable Types

The following table lists the variable types supported for use in a Form.

Variable Type	Icon	Editable Flag?	Required Flag?	Reset Value Flag?	Keep Value Per User Option?	Can be Added by User as a New Variable?	Support for Default Value(s)	Has a Value Field?	Representation on Form when Editable	Representation on Form when Read-Only	Applicable Process Themes
Data Set									Drop-down field for selection one release of the previously nominated project. Ability to point to Explorer window (button with three dots) Data sets within the chosen release are listed as clickable links	List of links	Project Activities
Date									Text field with date selection. Enter date manually (in format dd/mm/yyyy) or click on field to open calendar	Single line label	All
Dropdown								Single line text field with multiple values support (to specify the drop-down options)	Drop-down combo-box listing all defined drop-down options from which to choose	Single line label	All
File Upload									Drop-down area (drag and drop) Choose Files button List of links with possibility to remove	List of links	All
Item/Revision									Text field with type-in search Multiple values supported Ability to point to Explorer window (button with three dots)	List of links	All
Label								Multi-line text field	N/A	Multi-line label	All
Managed Project									Text field with type-in search Multiple values supported	List of links	All
Multi Line Text									Text field. Multi line.	Multi line label	All
Number									Text field. Single line with number validation	Single line label	All
PLM Publish Template									Drop-down field listing all currently defined PLM Templates appearing in the form <PLMInstance>:<PublishingTemplate>)	N/A	Project Activities
Project Template									Drop down when TC2 is in place Search with ... to go to explorer	Single line label	Project Creations
Properties									N/A	Table of properties key-value pairs Name of table as name of label When empty, not shown on the form	All
Run Web Review									Web Review button to launch Web Review interface for the nominated project	-	Project Activities
Single Line Text									Text field. Single line	Single line label	All
User/Group									Text field with type-in search Multiple values supported	Single line label Values separated by ','	All

Flags

Depending on the variable type for a field defined on a Form, it can have up to three flags:

• Editable – enable this flag to make the field editable, such as being able to enter the name of a project, enter a date, add data, and so on.
• Required – enable this flag to make the field a required field, meaning that the user has to choose an option, or enter data, to be able to submit the task.
• Reset value – enable this flag to have the field's value reset upon entry to the form. If a default value is applicable, and has been set, then this will be loaded, otherwise the field will be empty (or show Choose option if a drop-down field).

Examples of defined fields on a Form, along with their flags.

In terms of display, a flag can appear as follows:

• Blue – the flag can be changed, and is currently active.
• Grey – the flag can be changed, and is currently inactive.
• Dimmed Blue – the flag is active and cannot be changed.
• Not Displayed – the flag is not applicable.

Where a flag can be changed, click on it to toggle its active state.

Advanced Options

If a variable type supports additional options, there will be an associated Advanced options control – click this to expand and see them.

Examples of Advanced options for various defined fields on a Form.

The following options can be found here, depending on the variable type:

• Keep value provided by each user separately – allows you to use the field to 'pool' the values supplied in forms submitted by multiple users involved in a task, for example reviewing of a design.
• Dropdown options – for a variable of type Dropdown, define here the entries that can appear for user selection on the fields' associated drop-down menu.
• Default value – provide a default value to be presented 'pre-filled' as the fields' value when the user accesses the form associated to the task. If the field is of type Dropdown, the default value can be set to one of the defined Dropdown options, or set to None.
• Value – typically for a variable of type Label, use this field to define the label text, presented to the user on the form associated to the task they are working on, and descriptive of what they need to do.

Adding a Field

To add a new field to a Form, click the Add control at the bottom-right of the form. The new field is added to the bottom of the Form, with the Name drop-down expanded ready to either choose an existing variable already defined elsewhere within the process definition, or to create a new one.

Example addition of a new field to a Form. You can either choose to reference an existing variable defined for the parent process definition, or enter a new name, and in doing so create a new variable for that definition (once the Form is saved).

If an existing variable is chosen:

• It is added to the Form as another reference to the variable.
• The Name field is changed to a standard text field, allowing the name to be edited, but not for another variable to be chosen.
• Flags are set up in accordance with how the original variable has been defined.

If a new variable name is entered:

• The Name field becomes a standard text field.
• The variable Type can be chosen (default is Single Line Text).
• Flags are set up to a default state accordingly – Editable (active), Required (inactive), Reset value (inactive).
• The new variable is added to the process definition when the Form is saved.

To rename a field, click within the Name field and modify as required. If the field cannot be renamed, the Name will be greyed out, and the icon will appear if you hover over the field.

Removing a Field

To remove a user-defined field, click the control at its far right. The removal is instant, without any confirmation.

Reordering Fields

Any field can be moved to any position on the Form, by clicking and dragging the control, that appears at the left-hand side when hovering over a field. This enables you to add fields quickly to the Form, and then craft its appearance (order of those fields) thereafter.

Save & Deploy

Once a process has been defined as required, click the button (at the top-right of the editor) to have it added to the list of available processes for that process theme. The new process definition will be activated ready for use.