¶ 1. Abstract
The manual covers the T6 Planning Workflow BPM and addresses various topics related to configuring workflows, processes, parameters, responsibilities, email templates, activity design, task types, specific functions, and their syntax. The primary focus is on using the Business Process Modeling Notation (BPMN) to model business processes, aiming to provide greater flexibility to the classic workflow. The document also provides examples of expressions and detailed explanations of each part of the process, including task types, flow design, object identification, and other features associated with T6 Planning Workflow BPM.
¶ 2. Workflows
¶ 2.1 Overview
For each T6 Planning application, we must choose a workflow to be used. Each application can have only one type of workflow. The available types are:
- Classic
- BPM
The workflow type of an application can be changed at any time. To do this, simply edit the desired application and change the workflow type as needed.
Migrated applications will not have their workflow changed. New applications will default to the BPM workflow type.
¶ 2.2 Classic
An application configured to use the classic workflow will behave as the existing workflow in T6 Planning up to that point, where it operates based on the dimensions Scenario and Entity of the model. As the focus of this manual is BPM Workflow, we will not detail the Classic Workflow in this manual.
¶ 2.3 BPM
With the constant need for greater flexibility in our classic workflow, we sought a standard notation for business process modeling in the market. The most plausible option found was the Business Process Modeling Notation (BPMN), developed and provided as a new workflow option for applications.
Currently, a subset of BPMN is supported. Our long-term goal is to cover all available BPMN options.
Some additional options have been provided in the process creation to facilitate filling and executing processes, but these options do not belong to the BPMN standard.
¶ 3. Process
¶ 3.1 Overview
A process is a group of activities performed in a specific sequence. Processes are independent of the application. Only some specific task types, detailed later, are application-dependent.
The process is the definition of a flow. An instance is a running copy of a process. In the same process, we can have several instances running simultaneously. It is only possible to initialize an instance in a process if it is published.
When saving a process, no validation is performed. Consistency validation only occurs during the publication of the process.
Processes have version control. In other words, every time the process is saved, a new version of the process is saved, keeping the previous version in the process history for future reference.
¶ 3.2 Parameters
A process can have a collection of parameters. Each parameter has a type definition and a configuration. Each process only has parameter definitions, and each process instance must have a value for each process parameter.
If a parameter is configured to accept null values, filling is not required when the user needs to trigger an action.
A parameter configured as internal will not be visible in the parameter list when triggering an action. The purpose of an internal parameter is to abstract the parameter for the user who will trigger the action, as the parameter is only necessary for the internal functioning of the process. Since the parameter is not listed, it is necessarily a parameter that accepts null values.
Below are the possible parameter types.
¶ 3.2.1 Action
Allows storing a value related to the action performed on an instance. For example: Whether the task was approved or not.
¶ 3.2.2 File
Allows the upload of files.
¶ 3.2.3 Boolean
Stores binary values true or false, enabling use in conditionals, for example.
¶ 3.2.4 Date
Used to store a date.
¶ 3.2.5 Decimal
Used to store a floating-point value.
¶ 3.2.6 Integer
Used to store an integer value.
¶ 3.2.7 Member
Used to store the identification of a member of a specific application and dimension.
¶ 3.2.8 Name
Used to store the instance's identification. If this parameter exists in a process, whenever T6 Planning needs to identify an instance, it will use the value contained in this parameter.
¶ 3.2.9 Responsible
Used to store a list of responsibles.
¶ 3.2.10 Single Responsible
Used to store a single responsible.
¶ 3.2.11 Data Table
Used to store the identification of a specific data table.
¶ 3.2.12 Text
Used to store text.
¶ 3.3 Responsibles
Defining the responsibles for the tasks of a process can be a very laborious and difficult maintenance activity. To facilitate defining the responsibles for the tasks of a process, it is possible to configure the process to load the responsibles stored in a data table. To do this, simply choose the data table where the responsibles' information is stored and configure some identification columns.
Below is a description of how to configure the parameters to dynamically load the responsibles:
- Responsible Data Table: Choose the data table where the information about the responsibles is located.
- Identification Column: Choose a column from the data table of type text that has an identification for the task we want to load the responsibles. At the time of loading the responsibles for a task, the value contained in the "Task Identifier" of the task will be used as a filter in the selected "Identification Column."
- Responsible Column: Choose a column from the data table of type text that has the user's identification. To facilitate filling in this column in the data table, it usually has a link to the T6 Planning users in the data table definition. With this, in the data form, we will have a selection box to choose the desired user.
- Sorting Column: Choose a column from the data table of type integer. This parameter, not mandatory, is only necessary if there is a need to use multiple responsibles in our tasks.
- Filters: If there is a need to filter the responsibles of the tasks contained in a data table, we can use filters to map a process parameter to a data table column. To use this functionality, the process must have a parameter of type "Responsible," and a parameter of type "Responsibles" is also necessary.
¶ 3.4 Email Templates
To facilitate email configuration, it is possible to create email templates in the process. After configuring the email template, we can associate it with predetermined events in the process or task.
- Start: By associating an email template with the start event, an email with the associated template will be sent every time a new instance is started.
- Stop: By associating an email template with the stop event, an email with the associated template will be sent every time an instance is stopped.
- End: By associating an email template with the end event, an email with the associated template will be sent every time an instance is finished.
- Start Task: By associating an email template with the start task event, an email with the associated template will be sent every time a task is started.
- Approve Task: By associating an email template with the approve task event, an email with the associated template will be sent every time a task is approved.
- Reject Task: By associating an email template with the reject task event, an email with the associated template will be sent every time a task is rejected.
- Task Deadline: By associating an email template with the task deadline event, an email with the associated template will be sent for each task that is not overdue and has time remaining below the configured value in the process when T6 Planning Services is executed with the "sendmaildeadline" option.
- Delayed Task: By associating an email template with the delayed task event, an email with the associated template will be sent for each overdue task every time T6 Planning Services is executed with the "sendmaildeadline" option.
¶ 3.5 Design
The definition of the activity flow in a process is done through a graphic designer. When creating a new process, the designer will create a Start activity and an End activity for the process.
Whenever an activity is selected by clicking the mouse's first button on the activity, the designer will display around the selected activity which other possible activities can branch off from the current activity. If no options are available, it means that the current activity cannot have any more activities branching from it.
To access the available actions for an activity, simply use the mouse's second button on the desired activity. A context menu will be provided with actions for the activity.
If a double-click is performed on the activity, the designer will execute the expected default action for that activity, usually the first available action from the context menu for the activity.
To move an activity, just select it and perform the drag-and-drop movement to the desired new position for the activity.
Some activities support resizing. To resize, simply select the activity and perform the drag-and-drop movement at the bottom right corner of the activity. Note that when the mouse is at the bottom right corner of the activity and the activity supports resizing, the mouse cursor will change to the resizing cursor.
¶ 3.5.1 Identifying Workflow Objects and Activities
The T6 Planning workflow follows BPM rules, where each object available in our tool represents an activity, as follows:
- Start: Used to identify the start of a process, sequence, or sub-process. Every flow must have only one Start. For this reason, it is not possible to insert or remove the Start from a flow.
- End: Used to identify the end of a process, sequence, or sub-process. Every flow must have only one End. For this reason, it is not possible to insert or remove the End from a flow.
- Subprocess: Allows the use of one process within another, provided both processes are compatible. In other words, in mapping the process to the subprocess, all parameters of the subprocess must have a corresponding parameter in the process, of the same type or equivalent.
- Sequence: Used to group activities within a process, allowing abstraction and simplification of a process.
- Conditional: Used to divert the flow of a process. Every conditional must have an expression to be validated. The result of this expression must be a boolean value. If the result is true, the instance will be diverted to the green connection. If the result is false, the instance will be diverted to the red connection.
Below is the expected syntax in a conditional expression:
[Comparative Block]
Where:
[Comparative Block] = [Comparative] or [Comparative] and [Logical Operator] and [Comparative Block]
[Comparative] = [Operand] and [Comparator] and [Operand]
[Operand] = Can be any function or a constant. For more information on functions, see the list of functions.
[Comparator] = "<=" or "=" or ">=" or "!="
[Logical Operator] = AND or OR - Divider: Used to create instances in the flow. A divider can have as many output connections as necessary. For each output connection of a divider, a new instance will be generated. If an expression is used in the divider, for each resulting value in the expression's loading function, a new instance will be generated for each output connection of the divider. The resulting value of the loading function will be filled in the parameter specified in the instance function in the new created instance.
Whenever an instance encounters a divider, new instances will be created in the flow, and the original instance will be moved to the junction corresponding to the divider with the waiting state. When the last instance created in the divider reaches the junction, the original instance will exit the waiting state and continue the flow with the executing state.
Below is the expected syntax in an expression of a divider:
[Instance Function] = [Loading Function]
[Instance Function] must be the Instance function. For more information on the Instance function, see the list of functions.
[Loading Function] must be a loading function. For more information on loading functions, see the list of functions. - Junction: Used to join two or more connections in a flow. Whenever there is a conditional or a divider in the flow, there must be a corresponding junction for it.
- Lane: Used to designate the responsible party for a task in the process flow. Each lane in the process must be associated with a lane in T6 Planning. Thus, the person responsible for a task in the flow will be defined by the users contained in the T6 Planning lane. In a process, we can have multiple lanes. There is the possibility of having two lanes in the flow pointing to the same T6 Planning lane.
- Task: Designates an activity that is not linked to the operation of the process flow but rather to the objective of the process itself. A task can be automatic or manual. If it is manual, it will have at least one person responsible for its execution.
Below are the possible types of tasks available:- Data Load: This type of task aims to execute data loads, whether it be a dimension load or a fact load. It requires the choice of a specific application. Being a manual execution task, it requires the definition of a responsible user.
- Automatic Data Load: Similar to Data Load, but this will occur automatically.
- SQL Command: Allows the user to enter an SQL command to be executed by the task.
- Email: This type of task aims to send an email. It has no dependency on any application. Being an automatic execution task, it does not require the definition of a responsible user.
- Expression: This type of task aims to execute expressions. There is the possibility of inserting multiple expressions in the same task. To do this, simply put each expression on a different line. It has no dependency on any application. Being an automatic execution task, it does not require the definition of a responsible user.
Below is the expected syntax in an expression of a task:
[Storage Function] = [Function or Constant]
Where:
[Storage Function] must be a storage function. For more information on storage functions, see the list of functions.
[Function or Constant] can be any function or a constant. For more information on functions, see the list of functions. - Formula: This type of task aims to execute formulas. It requires the choice of a specific application. Being a manual execution task, it requires the definition of a responsible user.
- Automatic Formula: Similar to Formula, but this will occur automatically.
- Form: This type of task aims to open a form for information filling. There is the possibility of associating the process parameters with the form pages. Thus, when opening the form through the task, the pages will be selected according to the value of the parameter contained in the current instance. It requires the choice of a specific application. Being a manual execution task, it requires the definition of a responsible user.
- Data Form: This type of task aims to open a data form for information filling. There is the possibility of associating the process parameters with the data form pages. Thus, when opening the data form through the task, the pages will be selected according to the value of the parameter contained in the current instance. It requires the choice of a specific application. Being a manual execution task, it requires the definition of a responsible user.
- Hyperlink: This type of task aims to open a hyperlink. It has no dependency on any application. Being a manual execution task, it requires the definition of a responsible user.
- Automatic Hyperlink: Similar to Hyperlink, but this will occur automatically.
- Data Link: This type of task aims to execute data links. It requires the choice of a specific application. Being a manual execution task, it requires the definition of a responsible user.
- Publish: It will publish the Cube of the selected application in the task. It is the same action as going to the "Modeling" menu -> "Publish".
- Reload Members: It will reload the members of the selected dimension in the task (according to the selected applications as well) that are in the database. It is the same action as going to the "Modeling" -> "Model Structure" -> "Members" screen and in the screen's "Tools" menu, "Reload Members" action.
- Report: This type of task aims to view a report. It requires the choice of a specific application. Being a manual execution task, it requires the definition of a responsible user.
- Automatic Routine: This type of task aims to execute a SQL Server job automatically. It has no dependency on any application. Being an automatic execution task, it does not require the definition of a responsible user.
- Manual Routine: This type of task aims to execute a SQL Server job manually. It has no dependency on any application. Being a manual execution task, it requires the definition of a responsible user.
- Scenario Types: Allows changing the scenario types (whether the scenario is closed, planned, or realized) of the application. It is the same action as going to the "Modeling" menu -> "Scenario Types".
¶ 3.6 Functions
The T6 Planning Workflow BPM allows the insertion of some functions with specific purposes within the process, as described below:
¶ 3.6.1 CreateDataTableRow
The CreateDataTableRow function is used to create a record in a data table.
PARAMETERS:
- Data Table: Name of the data table.
- Column and Value: Optional multivalued parameter used to define the values of the columns of the new record in the data table.
EXAMPLE: Instance(Monthly Billing Consumption) = CreateDataTableRow([Monthly Billing Consumption], [Consumption Unit] = Instance(Unit), [Month] = Instance(Month))
In this example of an expression of a task of the expression type, a new record in the Monthly Billing Consumption data table is created, where the value of the Consumption Unit column will be filled with the parameter of the instance named Unit, as well as the value of the Month column of the record will be filled with the parameter of the instance named Month.
¶ 3.6.2 DataLoadParameter
The DataLoadParameter function is used to manipulate the data load parameters of a specific application, and the function can be used to load or save a value of a data load parameter. This function is considered a storage function.
PARAMETERS:
- Parameter: Data load parameter composed of the application name and the data load parameter name.
EXAMPLE: Instance(Email) = DataLoadParameter([Quality].[Content])
This example of an expression deals with a task of the expression type. The value of the Content data load parameter of the Quality application will be assigned to the Email parameter of the current instance.
¶ 3.6.3 DataTableCell
The DataTableCell function is used to manipulate values of a record in a data table. It can be used to load or save a value from a record in a data table. This function is considered a storage function.
Parameters:
- Cell: Identification of a data table cell. Composed of the data table name, row identification, and column name.
Example: Instance(UEmail) = DataTableCell([Users].[Instance(ID)].[Email])
This expression example deals with an expression-type task. The value of the Email column from the Users data table, in the record identified by the ID parameter, will be assigned to the UEmail parameter of the current instance.
¶ 3.6.4 DataTableRowLookup
The DataTableRowLookup function is used to retrieve the identification of a record in a data table.
Parameters:
- Row: Identification of a record in a data table. Composed of the data table name, column name, and an expected value in the column.
Example: Instance(ID) = DataTableRowLookup[Users].[Name].[Instance(Current)]
This expression example deals with an expression-type task. The identification of the record in the Users data table that has the value in the Name column equal to the value of the Current parameter will be assigned to the ID parameter of the current instance.
¶ 3.6.5 GetDate
This function retrieves the current server date value.
Example: Instance(Data) = GetDate()
This expression example deals with an expression-type task. The server date will be assigned to the Data parameter of the current instance.
¶ 3.6.6 Instance
The Instance function is used to manipulate instance parameter values. It can be used to retrieve or save a value from an instance parameter. This function is considered a storage function.
Parameters:
- Parameter: Name of the process parameter.
Example: Instance(Action) = "Approved"
This expression example deals with an expression-type task. The constant "Approved" will be assigned to the Action parameter of the instance.
¶ 3.6.7 InstanceCode
Returns the code of the current instance.
Parameters: None
Example: Instance (Code) = InstanceCode()
¶ 3.6.8 InstanceName
Returns the name of the current instance.
Parameters: None
Example: Instance (Name) = InstanceName()
¶ 3.6.9 LoadDataTableRows
The LoadDataTableRows function is used to load records from a data table, and they can be filtered or not. This function is considered a loading function.
Parameters:
- Data Table: Name of the data table to have the records loaded.
- Filter: Optional multivalued parameter used to filter the records to be loaded. If more than one filter is defined, they will intersect the results. If consecutive filters where the left operand is equal are defined, they will unite the results.
Below is the expected syntax in a filter parameter:
[Operand] [Comparator] [Operand]
Where:
[Operand] = [Column] or [Constant] or [Instance] or [Expression]
[Column] =Name of a data table column. The column name should be enclosed in square brackets.
[Constant] =Value of a constant. The constant value should be enclosed in double quotes.
[Instance] =Instance function. For more information on using the Instance function, refer to the function details in the function list.
[Expression] =An SQL expression. The expression should be enclosed in curly braces.
[Comparator] = "<=" or "=" or ">=" or "!=" - Column: Optional parameter that should be used whenever you want to return a column other than the identification column of the data table.
Example: Instance(Activity) = LoadDataTableRows([Activities])
In this example of an expression task, the identifications of the records in the Activities data table will be assigned to the Activity parameters of the instances created by the task.
¶ 3.6.10 LoadMembers
The LoadMembers function is used to load members from a dimension, and they can be filtered or not. This function is considered a loading function.
Parameters:
- Dimension: Name of the data table to have the records loaded. Composed of the application name and dimension.
- Filter: Optional multivalued parameter used to filter the members to be loaded. If more than one filter is defined, they will intersect the results. If consecutive filters where the left operand is equal are defined, they will unite the results.
Below is the expected syntax in a filter parameter:
[Operand] [Comparator] [Operand]
Where:
[Operand] = [Column] or [Constant] or [Instance] or [Expression]
[Operand] = [Property] or [Constant] or [Instance]
[Property] =Name of a dimension property. The property name should be enclosed in square brackets.
[Constant] =Value of a constant. The constant value should be enclosed in double quotes.
[Instance] =Instance function. For more information on using the Instance function, refer to the function details in the function list.
[Comparator] = "<=" or "=" or ">=" or "!="
Example: Instance(Member) = LoadMembers([Planning].[Entity])
In this example of an expression task, the identifications of the members in the Entity dimension of the Planning application will be assigned to the Member parameters of the instances created by the task.
¶ 3.6.11 MemberProperty
Returns the name or value of a member property.
Parameters:
- Dimension: Name of the member's dimension. Composed of the application name and dimension.
- Identifier: Textual identifier (ID or UniqueID) of the member or value of an instance parameter.
- Property: Desired property name. If this parameter is not filled, the function will return the name of the member.
Examples:
Member([Application].[Dimension], "5")Member([Application].[Dimension], "[Account].[Account].[&5]")Member([Application].[Dimension], "[Account].[Account].[&5]", "Property")
¶ 3.6.12 ProcessDescription
Returns the description of the process.
Parameters: None
¶ 3.6.13 ProcessName
Returns the name of the process.
Parameters: None
¶ 3.6.14 RemoveDataTableRow
The RemoveDataTableRow function is used to remove records from a data table.
Parameters:
- Data Table: Name of the data table.
- Column and Value: Optional multivalued parameter used to define the values of filters for the removed columns.
Example: Instance(Units) = RemoveDataTableRow([Consumption Unit], [Contract] = Instance(Contract));
In this example of an expression task, the records in the Consumption Unit data table are removed, where the removal filter is the Contract column having the value of the Contract instance parameter. In this example, the Units instance parameter will receive the number of removed records.
¶ 3.6.15 Responsible
Returns the name and email of the person responsible for the task.
Parameters:
- Position: You can search for the 'Previous,' 'Current,' or 'Next' responsible. Use 'Previous,' 'Current,' or 'Next.'
Example: Responsible(Current)
¶ 3.6.16 ResponsibleEmail
Returns the email of the person responsible for the task.
Parameters:
- Position: You can search for the 'Previous,' 'Current,' or 'Next' responsible. Use 'Previous,' 'Current,' or 'Next.'
¶ 3.6.17 ResponsibleName
Returns the name of the person responsible for the task.
Parameters:
- Position: You can search for the 'Previous,' 'Current,' or 'Next' responsible. Use 'Previous,' 'Current,' or 'Next.'
¶ 3.6.18 Sum
The Sum function is used to sum the values contained in a multivalued parameter.
Parameters:
- Parameter: Name of the process parameter.
Example: Instance(Value) = Sum(Values)
In this example of an expression task, the sum of the values contained in the Values parameter will be assigned to the Value parameter of the instance.
¶ 3.6.19 TaskDescription
Returns the description of the current task.
Parameters: None
¶ 3.6.20 TaskName
Returns the name of the current task.
Parameters: None
¶ 4. Lanes
¶ 4.1 Overview
Lanes are used to organize and categorize activities according to their function or role.
A lane can have a collection of users or even a collection of user groups. The users contained in the lane, directly or indirectly, will have the function or role performed by the lane.
Lanes are independent of applications and models. Thus, the same lane can be used in various distinct processes.
Each lane belonging to a process has a one-to-one relationship to the lane.
¶ 5. Triggers
¶ 5.1 Overview
Triggers are T6 Planning mechanisms for creating new instances of a process. Triggers can be executed manually, automatically, or through T6 Planning Services.
When a trigger is fired, a new instance is created in the process predefined in the trigger's creation. The new instance is created at the start of the process and executed by the workflow execution engine until it encounters a manual task or reaches the end of the process.
¶ 5.2 Trigger Types
Triggers can be fired manually, automatically, or through T6 Planning Services.
- Manual: Every trigger can be manually fired. To do this, simply execute a trigger from the trigger list and fill in the necessary parameters.
- Automatic: A trigger can be configured to be automatically fired. To do this, in the trigger definition, it is necessary to configure a data table to be observed, where we must inform in which events the trigger should be fired.
For an automatic trigger to work, the process must have a parameter of type Data Table pointing to the same process the trigger is observing. This parameter will be filled in at the time of instance creation with the identification of the row that triggered the event. - T6 Planning Services: There is the possibility to configure a trigger to be executed automatically in T6 Planning Services. Whenever T6 Planning Services is executed with the StartInstance option, all triggers marked to be executed in T6 Planning Services will be fired. If necessary, it is possible to execute a trigger punctually through T6 Planning Services.
¶ 5.2.1 Trigger Firing Events
The available events for trigger firing are:
- Insertion: Every new row inserted into the data table will create a new process instance. The instance will be created after the insertion of the new row into the data table.
- Update: Every row updated in the data table will create a new process instance. The instance will be created after the update of the row in the data table.
- Removal: Every row removed from the data table will create a new process instance. The instance will be created before the removal of the row from the data table.
¶ 6. Execution
¶ 6.1 Overview
To execute a process, an instance must be initiated and parameterized. In addition, the definition of those responsible for the process activities must be made.
¶ 6.2 Instance
When a trigger is executed, manually or automatically, a new instance will be created. This initialized instance will have its parameter values filled with the values found in the trigger that originated the instance.
The new instance created will traverse the flow until reaching the end. During the flow, the instance may require manual action from a user. When this happens, the instance will wait for the interactivity of the user responsible for the current activity.
When manual interactivity is required, the user must perform an action in the activity.
The available actions are:
- Approve: This action approves the current activity and sends the instance to the next available manual activity. If there is more than one responsible in the activity, the instance will remain in the same activity and assign the next responsible if it exists.
- Reject: This action rejects the current activity and returns the instance to the previous responsible or the previous manual activity. To perform this action, the user must have specific permission, and the flow must be at a point where the action is valid.
- Stop: This action cancels the current instance. Once an instance is canceled, it can no longer be executed. To perform this action, the user must have specific permission.
- Pause: This action pauses all instances, preventing the process from continuing its flow. The same function that allows the user to stop an instance will also allow pausing and/or resuming an instance of a process.
- Resume: This action acts on a paused instance, resuming the flow execution to the state before it was paused.
- Pinch: Allows pinching (picking up) an instance and throwing it to another point in the flow. Crude example: The process is in "Task 5" of the flow, the user can pinch it and make the instance go back to "Task 1".
- Assign: This action assigns the responsible for the current instance to the user. By assigning the action to him, no other user can take action on the instance. This action is only available in activities with mixed responsibility.
- Unassign: This action unassigns the responsible for the current instance, allowing another user to assign the current instance. This action is only available in activities with mixed responsibility.
¶ 6.3 Responsibility
The responsibility of a manual activity can be defined in various ways, as described below.
¶ 6.3.1 Lane
When an activity is within a lane and the process does not have any responsible parameter type, the responsibility of the activity is visible to all users belonging to the lane.
¶ 6.3.2 Responsible Parameter
When an activity is not within a lane and the process has a responsible parameter type, the responsibility of the activity is assigned to the user defined in the responsible parameter.
¶ 6.3.3 Mixed
When an activity is within a lane and the process has a responsible parameter type, the responsibility of the activity will be visible to all users belonging to the lane until no user assigns the activity to himself. If a user assigns the instance to himself, only the assigned user will see the activity.
¶ 6.4 Dynamic Responsibles
An activity is considered to have dynamic responsibles when the process to which it belongs is configured to dynamically load responsibles from a data table. In this situation, whenever the instance enters a manual activity, the responsibles for the activity will be loaded from the data table and stored in the parameter of type Responsibles. The first responsible in the responsibles list will be stored in the Responsible type parameter.
¶ 7. Security
¶ 7.1 Overview
This topic covers role and function configurations of users responsible for process tasks.
¶ 7.2 Process Type Roles
A process type role allows the user to access cube information. When a user's roles are requested by the application, for each instance assigned to the user, a role containing the member type parameter information relevant to the application in question is created.
¶ 7.3 Functions
New functions have been made available to make access to new functionalities more flexible for users. Below are the new available functions:
¶ 7.3.1 Manage Process Structure
Users with this function have permission to create, edit, and remove processes. Available only for Manager users.
¶ 7.3.2 Manage Trigger Structure
Users with this function have permission to create, edit, and remove triggers. Available only for Manager users.
¶ 7.3.3 Manage Lane Structure
Users with this function have permission to create, edit, and remove lanes. Available only for Manager users.
¶ 7.3.4 Stop Instance
Users with this function have permission to stop a running instance. Available only for Manager users.
¶ 7.3.5 Pause Instance
The same function that allows the user to stop an instance will also allow pausing an instance of a process.
¶ 7.3.6 Resume Instance
The same function that allows the user to stop an instance will also allow resuming an instance of a process.
¶ 7.3.7 Pinch Instance
Users with this function have permission to pinch instances. Available only for Manager users.
¶ 7.3.8 Publish Process
Users with this function have permission to publish processes. Available only for Manager users.
¶ 7.3.9 Reject Instance
Users with this function have permission to reject a running instance. The option will only be available if the item from the previous process to the current task is a manual task. Available only for Planner users.
¶ 7.3.10 View Instance
Users with this function have permission to view instances. Available only for Planner users.
¶ 7.3.11 View Trigger
Users with this function have permission to execute triggers. Available only for Planner users.
¶ 7.3.12 View Process
Users with this function have permission to view processes. Available only for Manager users.
¶ 8. Examples
¶ 8.1 Overview
Below is an example of a process created with the new BPM workflow available in T6 Planning.
¶ 8.2 Expense Reimbursement
A user registers an expense reimbursement in a data form. If the reimbursement amount is less than R$500.00, the reimbursement is automatically approved. If the reimbursement amount is greater than R$500.00 and less than R$10,000.00, the reimbursement requires manual approval from a user participating in the reimbursement lane. If it is greater than R$10,000.00, the reimbursement is automatically rejected.
