Modeling 01 BPMProcesses Introduction Helium 20180928 PDF

Modeling
BPM Processes. Introduction

(September 28, 2018)
This publication belongs to the Documentation Service of AuraPortal (APDS) and all rights
are reserved. The reproduction total or partial of this document is not allowed, nor its trans-
mission to third parties without written permission by the APDS.
www.auraportal.com | info@auraportal.com | Skype: AuraPortal | Tel: +34 962 954 497 |
International: +18 572 390 070
CONTENTS
1. WHAT ARE BUSINESS PROCESSES AND BPM? ................................................................................................. 4
2. LIFE CYCLE OF THE PROCESSES ......................................................................................................................... 7
3. CLASS OF PROCESSES .......................................................................................................................................... 9

3.1. GENERAL DATA ............................................................................................................................................. 11
3.1.1. Actions Bar .............................................................................................................................................. 12
3.1.2. Identity Section ....................................................................................................................................... 14
3.1.3. Execution Section ................................................................................................................................... 25
3.1.4. Chronometrics Section ............................................................................................................................ 31
3.2. DIAGRAM ........................................................................................................................................................ 34
3.2.1. BPMN, BPEL and XPDL Standards ........................................................................................................ 36
3.3. OBJECTS ........................................................................................................................................................ 37
3.3.1. Tasks ...................................................................................................................................................... 39
3.3.2. Events ..................................................................................................................................................... 63
3.3.3. Gateways ................................................................................................................................................ 78
3.4. SPANS ............................................................................................................................................................. 81
3.5. BASE DOCUMENTS ....................................................................................................................................... 88
4. EXAMPLE OF MODELING ..................................................................................................................................... 89

4.1. DIAGRAM ........................................................................................................................................................ 90
4.2. OBJECTS ........................................................................................................................................................ 93
4.2.1. Step 1: 1.IM.1 Start Message ................................................................................................................. 94
4.2.2. Step 2. Personal Task 1.TP.1 Supervisor’s Approval ........................................................................... 108
4.2.3. Step 3. 1.DX.1 1st Approval?................................................................................................................. 115
4.2.4. Step 4. 1.DX.2 2nd Approval? ................................................................................................................ 119
4.2.5. Step 5. 1.ET.1 Only Monday & Thursday from 10:00 - 12:00 ............................................................... 119
4.2.6. Step 6. 1.TP.2 Approved by Division Manager ..................................................................................... 122
4.2.7. Step 7. 1.DX.3 2nd Approval? ................................................................................................................ 123
4.2.8. Step 8. Points of Control 1.K.1 and 1.K.2 ............................................................................................. 123
4.2.9. Step 9. 1.TP.3 Notifies of Approval ....................................................................................................... 123
4.2.10. Step 10. 1.DX.4 Material Available? ................................................................................................... 125
4.2.11. Step 11. 1.TS.2 Notifies of Delivery .................................................................................................... 125
4.2.12. Step 12. 1.TP.4 Collection of Material ............................................................................................... 126
4.2.13. Step 13. 1.TS.3 Updates Stock ........................................................................................................... 126
5. EXAMPLE OF EXECUTION .................................................................................................................................. 128

5.1. PROCESS INITIATION .................................................................................................................................. 128
5.2. PROCESS PERFORMANCE......................................................................................................................... 130
5.2.1. Task 1.TP 1st Supervisors Approval ...................................................................................................... 130
5.2.2. Gateway 1.DX.1 1st Approval? .............................................................................................................. 132
5.2.3. Gateway 1.DX.2 2nd Approval? ............................................................................................................. 132
5.2.4. Time Event 1.ET.1 Only Monday & Thursday from 10:00 - 12:00 ........................................................ 132
5.2.5. Personal Task 1.TP.2 Approved by Division Manager ......................................................................... 133
5.2.6. Gateway 1.DX.3 2nd Approval? ............................................................................................................. 134
5.2.7. Point of Control 1.K.1 ............................................................................................................................ 134
5.2.8. Personal Task 1.TP.3 Notifies of Approval ........................................................................................... 134
5.2.9. Gateway 1.DX.4 Material Available? .................................................................................................... 134
MODELING. BPM PROCESSES. INTRODUCTION Page 2 of 160

5.2.10. System Task 1.TS.2 Notifies of Delivery ............................................................................................. 135
5.2.11. Point of Control 1.K.2 .......................................................................................................................... 135
5.2.12. Personal Task 1.TP.4 Collection of Material ....................................................................................... 135
6. EXAMPLE OF MONITORING................................................................................................................................ 136
APPENDIX A1 - AURAPORTAL AND PROCESS STRUCTURE ............................................................................ 141

A1.1. CALENDARS .............................................................................................................................................. 142
A1.2. ROLES ........................................................................................................................................................ 142
A1.3. DICTIONARY OF TERMS ........................................................................................................................... 143
A1.4. WEB SERVICES ......................................................................................................................................... 143
A1.5. CONNECTORS ........................................................................................................................................... 144
A1.6. FORMS ........................................................................................................................................................ 145
A1.7. FAMILIES .................................................................................................................................................... 146
APPENDIX A2 - SECURITY: ACCESS CONTROL .................................................................................................. 148

A2.1. FAMILY PREFILTERS ................................................................................................................................ 148
A2.2. AUTHORIZATIONS IN CLASSES .............................................................................................................. 149
A2.3. SECURE ROOMS ....................................................................................................................................... 149
APPENDIX A3 – BPMN MODELING: OBJECTS ..................................................................................................... 150

A3.1. TASKS ........................................................................................................................................................ 150
A3.2. SUBPROCESSES ....................................................................................................................................... 152
A3.3. EVENTS ...................................................................................................................................................... 153
A3.4. GATEWAYS ................................................................................................................................................ 155
A3.5. GATEWAYS (SPECIAL NOTATION) ......................................................................................................... 156
A3.6. ARTIFACTS ................................................................................................................................................ 157

1. WHAT ARE BUSINESS PROCESSES AND BPM?
The Processes are a collection of related, structured activities that constitute the overall activity of any
company or organization and are managed and controlled by systems known as BPM.
Acronym
BPM stands for “Business Process Management” and BPMS stands for “Business Process Management
Suite” or “Business Process Management System.”
Although BPMS identifies the software used to manage the operative processes in a company or organiza-
tion, the use of the term BPM is widely accepted for both purposes: the management itself and the soft-
ware that facilitates this management.
BPM is, without a doubt, the already consolidated and unstoppable trend that is changing forever the way
companies and organizations worldwide manage their operations, allowing them much greater flexibility,
automation and power.
Definition
BPM can be defined as:
“A new category of enterprise software that enables companies to model, deploy and manage sets of inter-
related activities -that is to say, Processes- of any kind, either within departments or permeating the whole
enterprise, with extensions to include the participation of customers, suppliers and other agents as per-
formers of process tasks.”
Scope
With a top of the range BPM tool like AuraPortal, the company can automate any process very easily, in-
cluding Human Resources, Quality Control, Purchase and Procurement, Customer Relationship Manage-
ment (CRM), Supply Chain Management, Risk Management, Sales, Invoicing and any kind of company-
specific processes.
Advantages
Companies that implement a BPM system improve their organization in all respects; weaknesses are un-
covered, and the most relevant activities are strengthened. In essence, it enables companies to be
more flexible, competitive and efficient.
Competitive and Economical Advantages

The huge competitive advantage that working with BPM signifies is such that a rapidly increasing number
of enterprises and organizations are adopting BPM tools in order to remain competitive compared to other
companies that are already working with the tool.
This is due to the fact that, aside from the superior power and operational flexibility contributed by BPM,
the enterprise's overall costs are reduced in the range of 20% to 50%, and the Return on Investment (ROI)
may reach a value as high as 400%.

Integration
Although the processes designed within the BPM can work comfortably and be integrated with existing
enterprise software such as ERP and CRM, it is likely that companies will gradually model the activities per-
formed by their ERP and CRM systems using the BPM, in order to substitute those applications with the
modeled processes, obtaining better automation, flexibility, solidity and power, as well as global unification
of the enterprise operations.
Three Steps in BPM

The procedure for working with processes comprises three fundamental steps:
Drawing a diagram of the process model.
Defining parameter values such as the names or roles of task performers, etc.
Putting the process into execution immediately without having to wait for any additional programming
(assuming you are working with AuraPortal).
Some examples of processes:

Purchasing.
Management of purchasing cycles.
Marketing.
Management of marketing and demand generation activities.
Sales opportunities.
Management of sales opportunities, including the control of commercial actions and the automatic gen-
eration of orders and contracts as appropriate.
Manufacturing.
Management of manufacturing or transformation processes.
Services.
Management of the provision of services.
Sales cycle.
Management of the cycle of sales, invoicing, charges and claims.
Customer Service.
Permanent hot-line for customers.
Accounting.
Accounting, including the assignation and control of budget allocations.
Human Resources.
Management of human resources, including: recruitment, salaries and fees, permissions, vacations, redun-
dancies, control and work performance
optimization, etc.
Finance.
Financial management, covering the control of money, loans, credits and debits, optimizing investment
destinations and cash flow applications.

Economic Situation.
Analysis of the company’s economic performance, its profitability, bottle necks and capabilities through
KPIs or key indicators.
Business Resources.
Integral optimization of business resources from a global perspective.
Strategies.
Design and monitoring of present and future strategies in all activity areas.
Performance standards.
Establishment and continuous update of performance standards in the organization.
Projects of any kind.

Design, monitoring and control of any kind of project, both unique and recurring and in both preparation
and execution stages.
Informative content.
Creation, update and publication of any kind of informative content, in any format and in any selected
media.
Document Management.
Intelligent and integrated management of all documents in the organization via potent File Systems that
can handle the creation, modification, search, printing, etc. of millions of documents very quickly.
Corporate website.
Controlled publication on the Internet and social networks, including periodic newsletters, the design of
web pages that can be dynamically updated, and the maintenance of blogs, chats, messages, etc.
eCommerce.
eCommerce with automatically updated offers, including shopping carts and payment gateways.
Legal procedures.
Management of the organization’s interaction with the legal framework for its operations, including any
legal and procedural processes that may occur.
Other actions.
Other actions and controls relating to the specific design procedures that each company or organization
needs depending on their particular characteristics, with unlimited complexity, for optimum individual per-
formance.
CRM.
Customer Relationship Management, which controls the relationships between the company and its cus-
tomers, suppliers, agents, etc., is optimally performed with Processes.
All of these are firmly settled in a grid-like workflow system that allows instantaneous and fluid communi-
cation between all the people that participate in the business activity, including not only employees, but
also external agents such as customers, suppliers, intermediaries, central administration and any others.

2. LIFE CYCLE OF THE PROCESSES
The Life Cycle of the Processes in AuraPortal is made up of 5 stages.
Here is a brief description of each one:
Modeling
Modeling is the stage where the Classes of Processes are designed, and is made up of two parts or stages:
- 1. Diagramming. This is the part of the AuraPortal Process Life Cycle where the diagram that
gathers the sequence, path and connections of all the objects included in a Class of Processes are
graphically designed.
This is performed with the AuraPortal Helium Modeler that comes included in AuraPortal, which is
explained in detail in the Helium Modeler Manual.
- 2. Attribute Assignment. After designing the Diagram, the second part of the Modeling involves
assigning Attributes to each of the Objects.
This stage, which encompasses the configuration of the general data of the Class of Processes and of the
Objects, is explained further on in this document. However, the design of the Forms, which are an essential
part of the Modeling as they house all the data necessary for the development of the Process, are ex-
plained in another independent series of documents found in the AuraPortal Knowledge Base.

Simulation
With AuraPortal it is possible to perform “simulations” of the running of the processes. This involves virtual-
ly executing the processes in imaginary situations to identify and quantify any circumstances that could
potentially influence the real running of these processes. These operations should reveal bottlenecks, over-
loads, an unequal distribution of workloads, excessive times, costs, etc.
AuraPortal offers two different complementary types of simulation:
- Statistical Simulation
- Real Simulation
Although this stage is configured from the general Class of Processes window, its full explanation has been
included in the Helium Modeler Manual.
Execution
After completing the Modeling and Simulation stages and the design of the Class of Processes is valid, the
Process can now pass to the Execution stage of its Life Cycle, which in AuraPortal terms is called the Pro-
duction Environment Mode.
In this stage, the users will work normally with the processes, introducing and consulting real data accord-
ing to the established design.
Monitoring
Once the users are working normally, the Process Monitoring makes it possible to control and supervise
that the Processes are being executed as expected or if there are any deviations that need correcting.
All the details related to the Modeling can be consulted in the documentation available about Information
Analysis and KPI.
Optimization
Whether or not the design of the Classes of Processes requires Optimization depends on the data obtained
through the Monitoring stage. If it is necessary, the BPM tool must allow instant modifications to be made
to the design of the processes and these modifications must be applied immediately in both the real and
imaginary environments, with no need for any programming. This characteristic is available in very few
BPM tools, only AuraPortal can truly offer it, because BPM tools in general require a certain level of inter-
vention from programmers or expert technicians to put any modifications made to the design of the pro-
cesses into execution. This makes it impossible to perform an elevated number of function tests on the
processes in a short time period, because the application would need to be reprogrammed in each case.
This document is the starting point for beginners wanting to learn about AuraPortal BPM. It includes expla-
nations on the general design of the Classes of Processes and in the complementary documentation you
will find all the details for assigning the attributes to the objects and for completing the design of the pro-
cesses. These complementary documents are:
- Delegated Administrator Manual

- Helium Modeler Manual

- Dynamic Forms
- System Tasks
- Document Management
- Groups of Fields and Distributed Treatments
- Secure Rooms
- Etc.
3. CLASS OF PROCESSES
The first stage involves the creation of a Class of Processes to control a specific issue in the entity. In Au-
raPortal, each Class of Processes has its own Model.
This model is subsequently applied to all the Processes in this Class.

As a real example we could have a Class of Processes called Sales Cycle, with this Model:
The processes of this Class manage each and every sales operation.
To create the Class of Processes, go to the Modeling window in Structure – Processes-Tree and Classes.
The window will look like the following:

Here the Modeling tool, AuraPortal Helium Modeler, can be accessed, and the General Data of the Class of
Processes introduced. The window includes an actions bar and three sections: IDENTITY, EXECUTION and
CHRONOMETRICS.
The details are explained below.
3.1. General Data

Here the data related to the Identity of the process is introduced and the data related to the Chronomet-
rics, such as the Calendar and the Clock. If some options are left blank, the system will provide the required
data by default.
Once the Class of Processes has been created, the model must be built. The Models of Classes of Processes
are created in two stages in AuraPortal:
- Stage 1. DIAGRAM. Draw the diagram with the objects and their connection lines.
- Stage 2. OBJECTS. Assign the defining attributes to each object.
Once this is done, the processes of this class can be generated and executed automatically. No program-
ming is required.
The General Data page is explained in detail below.

3.1.1. Actions Bar
The Actions Bar contains the generic buttons Exit, Save and Delete, as well as the Mode, Versions, Security
and Cache buttons.
Mode (1)
Here the situation of the Class of Processes can be defined. The following Modes are available:
1. Development Environment. This mode permits the development of a Class of Processes in its corre-
sponding version. Processes can be executed in this mode if the administrator deems it necessary.
2. Testing Environment. In this mode, it is not possible to modify the Modeling of the Class of Process-
es, but it is possible to make simulations of the developed Process because the Process Motor is acti-
vated. The data generated in simulation, although saved as if it were in Production Environment mode,
can be deleted if so desired when passed to Production Environment mode.
When the Mode of a Class of Processes is changed from Development or Testing Environment to one
of the Production Modes (Restricted or not), it is also possible to choose whether to:
• Delete any existing data created during the simulation (Testing Environment).
• Keep the data from the simulation as real data.
3. Restricted Production Environment. This does not allow new Processes of this Class to be created,
but it allows the already initiated ones to continue.
4. Production Environment. This is the mode that permits initiating (creating) and performing the Pro-
cesses in real, Productive mode.
5. Blocked. This is a special case. It occurs when, from Production Environment mode (Restricted or not),
the Class of Processes Responsible interrupts the initiation of all started Processes of this Class,
probably due to functioning problems. Nor is the initiation of new Processes of this Class allowed in
this mode.
Note.
When a Class of Processes is in Blocked mode, besides the fact that the BPMS Motor
stops managing its current threads in the diagram, the tasks disappear from the
users’ My Tasks list so that they cannot be performed.
6. Disabled. This is the mode for when the Class (or Version) is no longer used. It can only be used if
there are no running Processes of this Class (or Version). It does not allow new Processes to be initiat-
ed.

Note.
The different Class of Processes modes are designed to be kept isolated and pro-
tected in such a way that they don’t affect the functioning of the Processes that are
in Production, even though they are housed in the same AuraPortal installation.
Versions (2)
This is used when modifying a Class of Processes in Production with some Processes running. In actual fact,
a new Version of a Class of Processes is equivalent to a new Class. What the system does in order to permit
the development of the new version is consider it as a new Class, but with the current version as a base.
Note.
Combining the Versions and the Class of Processes Modes: Production Environment,
Testing Environment and Development Environment, there can be Classes of Process-
es in Production with users working with real data, while at the same time other Clas-
ses of Processes or versions of them are being modified and tested.
This is all carried out in the same AuraPortal installation and can be combined with
the possibility of performing prior tests in a backup installation.
With the Three Synchronized Environments Complement, the control and security
goes a step further, because it allows for the three Environments to be physically sep-
arate on three independent installations. That is, that any changes to the design and
the testing of the Classes of Processes are performed in different and independent in-
stallations from the one that contains the real data.
Security (3)
This includes two options:
• Shielded. The Shielded window will open on selecting this option. By entering a password, the
Class of Processes will be Shielded making it invisible to anyone who does not know the pass-
word that it was shielded with.
• Permissions. This option is exclusive to Adminportal, who can assign Editing or Reading permis-
sions to the Class of Processes to one or several groups of employees. For more information
about Permissions in Structure Options, refer to the Delegated Administrator Manual.
Cache (4)
Situating the cursor over the Cache option will open a submenu with the option: Regenerate Cache:

This option will empty the cache of all the forms in the Class of Processes. The individual forms have an
integrated mechanism that deletes the cache when the form is saved.
3.1.2. Identity Section

The first time the modeling window is accessed only the reduced IDENTITY section is shown. To create a
Class of Processes, enter a name and click on Save for the rest of the options and sections to appear:
The full Identity section contains the following fields:
Key. This is a key for associating Classes of Processes according to criteria characterized by each entity.
When creating a Class of Processes, by clicking on the configuration icon, one of the keys defined in the
Dictionary of Terms can be selected (this is explained in another section of this document). This key can
be modified at any moment and will form part of the Process Base Reference, along with the Class of Pro-
cesses ID and its Version.
Process Identification: Base Reference

When a Class of Processes is created, the system generates a unique identification code that includes
a Key, a Class number and a Version number. This code identifies the Class of Processes.

When a Process is initiated within a Class, the system takes the Class code and adds the order № of
the Process initiated within this Class. This forms the Base Reference of the Process, which is un-
changeable and will serve in the future for differentiating this Process within its Class.
This Base Reference is very useful. In the company for example, if various Processes of the Class Materi-
al Purchases are initiated simultaneously and the invoice of a supplier is received, which of the Process-
es does the invoice belong to? AuraPortal provides a mechanism based on the Process Base Reference,
which entails incorporating this Base Reference to every document or activity related to this Process.
With this, the system addresses every Message (Invoice, Order, Offer, etc.) to the correct Process with
no chance of error and without human intervention.
Moreover, a Process can optionally receive, as Reference Base amplification, more helpful information
that expands this Reference, like the name of the purchased material or the supplier, making it easier to
visually identify the Process among others of its Class. This additional information is provided by two
Form fields. Themes are designated and when designated, the information is automatically added to
the Base Reference, this way forming the Extended Reference.
Example
Let’s suppose we have a Class of Processes named: Work Investment Approval.
▪ The Key provided on creating the Class is PE (Process Example)
▪ The ID № provided by the system is 34
▪ The Version is № 1
With all this, the code of the Class of Processes is:
Class of Processes Code = EP34.1
The first Process of this Class to be initiated will have an order number = 1, so the Base Reference of
this Process will be:
Base Reference = EP34.1_1
Let’s also suppose that, in the Message Form used to initiate the Process, appear two Themes: ‘Work’
and ‘Investment Object’ with the following values:
Work = Jeresa Sports Airport
Investment Object = Control Tower
In that case the Extended Reference of this Process will be:
Extended Reference = EP34.1_1_Jeresa Sports Airport_Control Tower
This Reference system is the one used in all the BPMS Processes of AuraPortal.
Note.
The fields that you wish to use as Themes are selected once they have been added
to the form. This can be changed later on using the corresponding System Task. For
more information, refer to the documentation about Dynamic Forms and System
Tasks.
The rest of the fields in the IDENTITY section are explained below.

Version. This shows the version of the Class. Versioning is performed by the system when a Class of Pro-
cesses in Production, that has some running Processes, is modified.
Documentation button.
This button includes the functionality provided by AuraPortal for documenting the Class of Processes. It
opens a window with two options: Generate Descriptive Document and Generate Detailed Document.
The Design Basis button (1) in the actions bar allows documentation that could be relevant to the Class of
Processes to be integrated or associated.
Generate Descriptive Document (2)
To create a Descriptive Document of the Class of Processes which includes information about the diagram
and the configuration of the Objects.
In the Motivation field, text can be included that will appear in the Descriptive Document. Clicking on the
Generate Descriptive Document button will create the document in the chosen Format.
Generate Detailed Document (3)
This will create a Detailed Document of the Class of Processes that includes not only what is provided in
the Descriptive Document, but also the complete configuration of all the intervening objects. As the in-
formation is so complete, a series of filters is provided to refine the result. See the image below:

All four boxes can be marked: General, Panel, Diagram and Objects/Subprocesses, or any combination of
them.
General box.
If this option is marked, the Detailed Document will provide the General information of the Class of Pro-
cesses, which is what is covered in this chapter. See an example in the following image:

Panel box.
If this option is marked, the Detailed Document will provide information about the Fields included in the
Class of Panel of the Class of Processes; the ones that appear in the Panel field in the EXECUTION panel, in
the main configuration page of the Class of Processes which is explained further on.

As can be seen in the image above below the Fields box, all the fields will be displayed with their corre-
sponding configurations if the box is left empty. If a specific field is desired, the complete name or part of
it followed by an ‘*’ can be written in the box. If several fields are desired, they must be written separated
by a ‘,’. See an example below:
Diagram box.
If this option is marked, the Detailed Document will display the complete Diagram of the Class of Pro-
cesses if the box is left empty, individual pages if the desired page numbers are introduced separated by
commas, or a range of pages if the first and last pages of the desired range are introduced separated by a
hyphen.

See a diagram example in the image below:
Objects marker.
If this option is marked, the Detailed Document will show all the objects in the diagram and their configu-
ration, if the box is left empty.

If a specific object is desired, the complete name or part of it followed by an ‘*’ can be written in the box.
If several objects are desired, they must be written separated by a ‘,’, as shown in the given example. See
an example below, which is part of the information in a Start Message:

Subprocesses marker.
If this option is marked and the Codes box is left empty, the Detailed Document will show all the Subpro-
cesses in the complete diagram, including all their objects. If a specific Subprocess is desired, the com-
plete name or part of it followed by an ‘*’ can be written in the box, and all the objects in the requested
Subprocess will be included. If several Subprocesses are desired, they must be written separated by a ‘,’,
as shown in the given example.
Once the desired filter has been established, click Proceed. The Detailed Document will be generated in
Word format (docx). When entering this page again, the last performed filter will be shown.
Going back to the IDENTITY section…
Export button.
This button exports the Diagram or the entire Class of Processes, which can then be implemented in an-
other AuraPortal installation using the Import function explained further on. The following window will
open on clicking the Export button:
The Export only Diagram button created a file with the format: BPM_169.2.bpmn, where 169 is the ID of
the Class and 2 is the version. This file, which is saved on the local disc for example, can be subsequently
imported from the Structure option: Processes – Tree and Classes – Import.
The Export Complete Class of Processes option creates a GEN-218.1.IMP.AP file, with the reference of the
Class, in the selected SharePoint Library. This file can subsequently be imported from the Structure option:
Processes – Tree and Classes – Import.

Name. The name of the Class of Processes.
Description. An optional description of its function.
Maximum Number of Loop Recurrences. This field allows for infinite loops to be avoided in the process if
the Diagram has been designed incorrectly. The default value is 1000. When the motor detects that a
gateway has reached the limit of permitted recurrences, it will stop the process in question, show a mes-
sage in the Event Viewer and send a notification to the process responsible with the data of the stopped
process.
At this point, it will be possible to Resume the stopped process from the process tracking window. It will
only be resumed if the limit has been increased, regardless of whether or not the configuration of the Class
of Processes has been corrected or not.
Model Author. The person that has created the Class of Processes.
Class Responsible. The Employee or Role responsible for the aspects related to this Class.
Responsible of each Process. The employee responsible for the Processes of this class.
The following tables show the relation of the functionalities and the type of information that each respon-
sible receives or adopts:
RESPONSIBLE OF THE CLASS OF PROCESSES
Participants in Personal Tasks EMERGENCY (Definable) They will receive notifications

generated on clicking the Emer-
gency button in the action bar of
the task.
Personal Task Chronometrics WARNINGS (Definable) They will receive Alerts and
Alarms when the time specified
for the task is met.
Process Chronometrics WARNINGS (Definable) They will receive Alerts and

for the process is met.

Block the Class of Processes MODES They can change the Production
Environment & Restricted Pro-
duction modes to Blocked.
TS-NOTIFIER to Employees RECIPIENT (Definable) They will receive the notification.
TS-CREATOR of Own Family INTERNAL FIELD: Creator (if the They appear as creator of the
Elements Process Responsible does not element.
exist).
Notifications Initiation of Processes with Spe- They will receive notification of

cial Modules (SO & MC) but the user who has tried to start a
without correct license. process for a Module they don’t
have a license for.
Processes detained in TPs with They will receive notification that

Performers that don’t have the the process is detained in a Per-
correct Special Module licenses. sonal Task in one of the Modules
that the performer does not have
a license for.
Blocked Processes They will receive notification that

the process is blocked.
RESPONSIBLE OF THE PROCESS

the task.
Process Chronometrics WARNINGS (Definable) They will receive Alerts and

for the process is met.
TS-NOTIFIER to Employees RECIPIENT (Definable) They will receive the notification.
Process Panel SYSTEM FIELD in each Panel. The _Responsible field from the
Process.
Tracking MODIFICATION OF PANEL DATA As of version 4.3, process panel

field data can be modified.
Process Monitoring or Queries Such as SPECIAL PERMISSION They can see the processes they
are responsible for even though
they don’t have permission in the
Class of Processes due to the

applied Secure Room.
TS-CREATOR of Own Family INTERNAL FIELD: Creator (if the They appear as creator of the
Elements Process Responsible does not element.
exist).
Notifications No performer was found They will receive a notification if a

Personal Task doesn’t have a
performer.
Problem executing TS uploads. They will receive a notification if

an error is produced in a TS UP-
LOADER upload.
Comments made from the Status They will receive a notification

button in ‘My Message Status’. with the comments added from
‘My Message Status – Status
button – Add Comments button.
Processes forcibly detained due They will receive a notification

to excessive loops in gateways. about the detained process due
to a bad design which produces
excessive loops.
Secure Room. This manages the security of the Class of Processes. If none is selected, the system will apply
the _Open room, which has no limits in regard to permissions. To see the details of applying Secure Rooms
to Classes of Processes, consult the documentation about Secure Rooms.
Just introducing the Name of the Class of Processes and clicking Save is sufficient, because to rest of the
elements are either not mandatory or are introduced by the system by default. All of these elements can be
introduced or modified at any moment.
3.1.3. Execution Section
Diagram
From this option the Diagram of the model can be created or edited. Refer to the Diagram section for more
information.
Objects
Here the attributes are given to the different diagram objects. Refer to the Objects section for more infor-
mation.

Panel
Each Class of Processes has a Class of Panel, where the terms necessary for collecting or displaying the
Process information are added from the Dictionary of Terms. Later on, when a Process is created of this
Class of Processes, a Panel will automatically be created for this Process, with a copy of the terms added in
the Class of Panel. Each Process from a particular Class of Processes has its own Panel, separate from the
Panels of the other Processes. From this Panel option, it is possible to see, add and delete fields from the
Class of Panel without having to go the form of the Personal Tasks or Messages.
Clicking on the Panel icon will open the following window:
(1) The filters: Name, Description, Term Type and Data Type, match the columns of the grid the fields
are displayed in.
(2) Clicking on the name of a field in the grid will open the Class of Panel window, like the following:
Internal Name shows the internal name of the field, which can also be seen in the Selected Fields List in the
form design. This eases the configuration of certain features that require this data, such as in the design of
Excel Base Documents, JSON files, to start processes via REST web services, and other similar integration
options.
Location informs of the Object, the Form and the Division where the field is being used.

Dictionary Configuration gives access to the configuration of the field in the Dictionary.
(1) To access the Dictionary, click on the Aggregate Fields button to open the window for selecting the
terms. If the fields you need do not exist in the dictionary, they can be created from here. Once the desired
fields have been selected in the Dictionary they will be introduced into the Class of Panel.
(2) The Garbage Cleaner button will delete all the fields in the Panel of the Class of Processes that are not
being used in any Form, Object, Condition, Automatic Document, Recursive Paragraph, etc.
(3) Clicking on the See Conditions button will open the Fields in Conditions window, which shows the
Panel Fields that are being used as Conditions in the Class of Processes.
Clicking on the configuration icon of one of the fields will show the object(s) in which the condition is be-
ing used.

In this example, in the Start Message (1.IM.1 Start Process – by AURA employee) and a in Personal Task
(1.TP.2 Sentinel of Chain of Custody). Clicking on the search icon will open a window showing data relative
to the object.
And clicking on the Condition Viewer search icon, the complete condition will be show.

Comment Logs
The Comment Logs of a certain Process contain who has participated in each Personal Task, when they did
so, as well as the comments added by the successive participants. Each Class of Processes can have as
many Comment Logs as desired, which can act in all or some of the Tasks. This way, only the information
relevant to each user will be available in their Personal Tasks.
To create a Comment Log you simply give it a Name. It isn’t necessary to create Comment Logs from this
option, as AuraPortal also allows them to be created at the time of configuring a Task.
Once the Comment Log is created, the grid will show a column titled Register, and each created Comment
Log will have a checkbox in this column. See the image below:
If the checkbox is selected, the Comment Log will register that the current has passed through it in all the
forms of the process that it is included in, even if the performer does not leave a comment. If it is not se-
lected, only the comments will be registered.
Simulation
This feature only applies to the Classes of Processes that have been diagrammed with the AuraPortal Heli-
um Modeler and allows simulation patterns to be executed with multiple variables (chronometrics, % gate-
way outlets, etc.) to check the viability and performance of the design. This enables the detection of bottle-
necks and inconsistencies in the design of the diagram.

There are two types of simulation: Real Simulation and Statistical Simulation, which is the type configured
in this option. It is based on the introduction of probability data of the events considered critical in the
process being studied, for example, the estimated duration of one or more tasks within the process, the
resources associated with specific actions, their costs, etc. With these imaginary data, “what if” results can
be predicted which help to identify bottlenecks, performance, costs, workloads and, in general, any neces-
sary KPIs can be identified.
A detailed explanation of the Simulation has been included in the Helium Modeler Manual.
Version Control
AuraPortal Helium Modeler allows control over the versions that are made of the Diagram. On clicking on
the icon, a window like the following will open:
The current version is indicated in the first line (1) and cannot be selected. The Restore Selected button
(2) allows a previous version of the Diagram, the one selected in the checkbox in the first column on the
left (3), to be restored. The Reconstruct Diagram button (4) reconstructs the Diagram from the existing
objects, with some restrictions which are explained in a warning message. The Maximum number of ver-
sions of the diagram option limits the number of Diagrams that the system saves.
Consult the Helium Modeler Manual for more complete and detailed information about this stage of the
Process Life Cycle.
Note.
The Download Complement link must be clicked to download the complement cre-
ated by AuraPortal which solves the problems caused by current internet browser
restrictions with the traditional and extended Java Applets used in several AuraPor-
tal features. The diagramming feature is one of them. This complement only needs
to be installed once, although the link will continue to appear.

The Execution Priority allows you to establish the priority with which the Class of Processes will be execut-
ed. The default value is 0.00, which means that no priority has been defined. If one is defined, the greater
the number the greater the execution priority.
3.1.4. Chronometrics Section
This section is responsible for measuring and controlling the times in relation to the Processes of this Class.
The data to be provided are:
Calendar. Here, the calendar used for the Processes of this Class is chosen. These Calendars will have been
created from the corresponding Structure option.
Process Clock. Here you can choose to use the Server clock or a Local one that indicates the time offset
according to the universal GMT time. The system makes all its calculations converted to GMT in order to
homogenize, but it translates them into the timetables selected in each case.
Duration. This is for setting the parameters used for measuring the durations related to the Processes of
this Class.
Unit. The duration of the Process execution can be defined in Days, Hours and Minutes, either Natural or
Working (counted by the Calendar indicated in the first question).
Critical Level. For choosing the importance of the control. Later on, the Monitoring will be able to make
controls according to the Critical Level.

Expected/Minimum/Maximum. For defining the range of the control. The Expected, Minimum or Maximum
duration can be defined:
• By directly entering the duration. For this, mark the Manual box and enter the number depend-
ing on the Unit determined in the first question. For example, in the image, for defining the max-
imum duration the box Manual has been marked. When doing this, a new field opened where ‘5’
has been entered, indicating that the process must be carried out in 5 working days.
• Through a field of the Class of Panel. The Class of Panel puts into groups all the Terms (as has
already been explained) that will be used in this Class of Processes and therefore contains the
fields that need to be controlled. With this system, the process duration will be defined according
to a Panel field.
Alert – Alarm. This question appears if controlling a Maximum duration. By marking Yes, the following two
fields appear:
Alert Threshold. For defining when the Alert should be triggered.
• An Alarm is triggered when it’s getting close to the Maximum duration.
• An Alert is triggered when it’s getting close to the established Threshold.
Warning Message to. For choosing the users that should be warned if the Alert Threshold is reached. These
users will automatically receive a Notification Task when the Alert and the Alarm are triggered.
3.1.4.1. Managing time zones for Process participants
Below is an explanation of how the configuration of the Class of Processes Clock affects the Process partic-
ipants.
There are two basic configurations:
• Process. In each Class of Processes, it can be determined whether the BPMS Motor will take into
account the time zone of the Server or the one indicated manually (Local option). This is included
in the Chronometrics panel, seen further up in this document.
• Employee. This is configured in the record of each employee (Private Data) and it can be indicat-
ed whether the Server time zone will be taken into account or the Local time zone, which is ob-
tained automatically from the employee’s computer.

The functioning will be the following, depending on the scenario:
Automatic Conversion:
In the following cases, the Date and Time will be recorded internally in the database in GMT and will be
shown (grids and forms) with the time offset configured for each Employee (depending on the Server or
Local as mentioned before):
• Automatic insertion, that is, any Date-Time that is registered automatically in AuraPortal (e.g.
start of a process, task termination, etc.). This way, each user will see the start time of a process
adapted according to their time offset.
• Manual insertion in Date-Time fields in forms. This way, if an Online meeting is arranged for
15:00 in Italy, the attendees from a country with a -6 hour time difference will see the meeting
time as 09:00.
• Assignment Rules. As a panel field, which will also be saved in GMT in the configuration to later
be resolved as any Date and Time panel field.
Without Conversion:
In the following cases, the Date or Date-Time will be saved and shown just as it is introduced, without con-
version:
• Date in Form. Date (without time) fields introduced by a user in a form are saved in the data-
base without conversion and shown just as they were introduced. This way, if someone indicates
that December 25 is a holiday, this date will be seen from anywhere in the world; the time offset
of the user looking at this value will not be taken into account.
• Filters. The Date and Date-Time values introduced in filters (e.g. in My Tasks or in Queries) are
recorded directly without time conversion. This means that, if a Public Query is recorded with a
specific date and time in one country, depending on the time zone it is executed from it can show
different results, which is logical.
• Inference Rules. On designing the rule it is saved directly, it is not converted to GMT. In execu-
tion it is compared with the client’s date/date-time which is converted according their time offset.

• TS-UPLOADER. Given that there are no Time fields, the date is saved directly, without conversion.
• Conditions. Saved directly, without conversion, as is the case with the Query filters. The result is
that, for example, if a condition says that a division is to appear at 09:00, it will appear at 09:00 to
each user according to their time zone.
• Planning Date. Saved directly. This way, if an employee arranges an appointment for 09:00, even
though travelling to another time zone, the planning will indicate that the appointment is at 09:00
in the new time zone.
• Task Notification Date. Saved directly, which means that if an employee establishes a Notifica-
tion to wake up a task at 09:00, if travelling to another time zone the task will wake up at 09:00 in
the new time zone.
3.2. Diagram
The model is created by clicking on the Diagram configuration icon in the EXECUTION panel in the General
Data page. This leads to the diagramming tool.
The diagrams of the Class of Processes are made with the AuraPortal Modeler which comes included in
AuraPortal, which places the shapes that represent the Objects on the drawing canvas. When the diagram
is saved, the system automatically codes and registers the objects, so that they are ready to receive their
attributes.
More information can be seen about the diagram further on in this document, and the complete infor-
mation about designing the diagram can be found in the Helium Modeler Manual.
There are two versions of the AuraPortal Modeler: AuraPortal BPM Modeler-Visio, which requires the
prior installation of Microsoft MS Visio (versions 2003/2007/2010), and AuraPortal Helium Modeler,
based on Java which requires no third-party programs.
Note.
AuraPortal Helium Modeler is available as of the AuraPortal Helium Model (version
4.3).
Clicking on the Diagram configuration icon will open the following window:

Here you can choose the Modeler you wish to use.
For more detailed information about using the two types of Modeler, refer to the corresponding documen-
tation.
However, AuraPortal also allows a Class of Processes created in another AuraPortal installation to be Im-
ported, from the installation it was Exported to. This possibility is especially designed for deploying Clas-
ses of Processes in different, independent environments from the original, for the commercial distribution
of a specific design for example. For this purpose, once the Import has been performed, the Class of Pro-
cesses must be adjusted to the needs and characteristics of the destination installation.
A Class of Processes can be imported from Structure – Processes – Tree and Classes. See the image be-
low:
Note.
• The Origin and Destination installations must have the same version of Au-
raPortal and Extension Pack.
• For more details about the import, refer to the Delegated Administrator
Manual.
There are two possibilities:

• Import only Diagram. Diagrams in Development Environment Mode can be imported from any
Class of Processes.
• Import complete Class of Processes. A .IMP.AP file is imported, which has been generated by ex-
porting a Class of Processes. More information further on in this document.
Depending on each case, it is calculated that between 80-90% of the configuration is imported.
The Classes of Processes Import – Export functionality has the following limitations.
• The origin and destination installations are treated as totally independent on all levels (Dictionary
of Terms, Users, etc.).
• The import can only be performed once. The same Class of Processes cannot be reimported a
second time after performing new changes in the design, because each import will create a new
Class of Processes.
• After the import, the Class of Processes must be adjusted to the new installation, which could
mean performing 20-30% of the design again.
Therefore, this option is not focused on the periodic transfer of new designs from Development to Produc-
tion.
The Three Synchronized Environments Complement goes one step further in control and security be-
cause it allows the three environments to be physically separate on three independent installations; i.e., the
changes to the design and the Class of Processes testing is performed on different and independent instal-
lations from the one that contains the real data.
3.2.1. BPMN, BPEL and XPDL Standards

AuraPortal uses the BPMN (Business Process Modeling Notation) standard for modeling its Processes. This
standard, considered the most modern and accepted, uses three Object categories in order to draw the
Models:
Activities. Comprised of the Tasks (both Personal and System) and Subprocesses.
Events. Thanks to AuraPortal’s flexible conception and its automations, the Events are only activated either
by a Message (Message Event), or by the arrival of a certain day and time (Time Event).
Gateways. Their mission is to redirect the Model’s flow currents from the inlets to the outlets according to
certain conditions. They can be Divergent or Convergent.
All the shapes that can be used in the Diagrams representing the Objects of the Models in AuraPortal are
explained in the corresponding appendix further on in this document.
The BPMN notation is a drawing Standard of BPMN Diagrams, built to facilitate and unify the graphic rep-
resentations of objects and connections in the Workflow diagrams. It is not a Process execution language,
but simply a Modeling. However, it can be ‘mapped’ (converted) into the BPEL and XPDL standards, which
are conceived for Process executions.
Therefore, the users who desire so can convert the models developed in BPMN into BPEL or XPDL execu-
tion languages, by following the ‘mapping’ instructions that those languages contain.

However, the AuraPortal BPMS does not incorporate methods of conversion into BPEL and XPDL, because
the power of these last two is very poor comparatively and it would therefore be contradicting to include
methods of limiting, instead of developing to maximum the functions contained in the program by origin.
AuraPortal Scope.
AuraPortal contains a great deal of options that allow the resolution of practically
all the cases that can be presented in a company or organization that wants to
function with BPM.
But most of the times, using a small part of these possibilities (about 40%) will be
more than enough, as this covers 90% of the practical requirements.
Therefore, the user shouldn’t feel like they’re not taking full advantage of the appli-
cation if they’re not using all the resources offered by AuraPortal. If the resources
used are sufficient for solving the necessities, the work is well done. The not used
resources are a security mattress for covering possible future demands, less com-
mon and of a more complicated concept.
The construction of a Process Model in AuraPortal is a job thought for being performed directly by the
business personnel. This means that the Company executive personnel, who know the necessary functions,
can do it without the need of preparation in a programming or a technical level.
The Model that, as already said before, belongs to the Class of Processes contains all the necessary infor-
mation for the Processes of this Class to be carried out automatically, controlled by the Motor of each pro-
cess.
A model is made up of its Objects, which are:
• Activity Classes = Tasks + Sub processes
• Event Classes
• Gateway Classes
With all their attributes, as well as the Connections between them, which are responsible for directing the
current flows, both linear and parallel inside the Process.
Moreover, the Model contains complementary information inside the Class of Processes itself and commu-
nication channels with the Structure of AuraPortal, as explained above, including connections with external
applications by the use of Adaptors.
Once the Model of a Class of Processes is carried out in a satisfactory way, the system is ready to Start
Processes of this Class without any need of programming.
The system interprets the Model directly in all its details, it generates the Tasks (both System and Personal
ones), it controls the Events and it directs the current flows according to what is defined by the Gateways
appearing in the Model.
3.3. Objects
From this option the attributes are given to the different objects included in the Diagram.

By clicking on the Objects configuration icon, the following window will appear, similar to the following:
All the Objects that appear in the Diagram, which is reproduced with a Viewer on the right of this window
(1), are also found on the left (2), grouped by their natures under the following tabs (3): Tasks, Events
and Gateways. Also, the Spans tab allows time Spans to be defined between Points of Control, while Base
Documents is for creating the templates for the creation of automatic documents in the processes.
The RE Table button (4) shows the Performers and the Responsibles of the different Personal Tasks in
the Class of Processes. The Performer is marked with a ‘P’, the Substitute with a ‘p’ and the Responsible
with an ‘R’. See the example image below:

The Responsible of the example task 1.TP.1 Approval IM Supervisor is the Performer of the Class of
Task; the Performer is the Start Message Creator and the Substitute is the Appointed Supervisor.
The Tasks tab will be active when entering this window, and will show a list of all the existing Task objects
in the Diagram.
3.3.1. Tasks
The Tasks that should be given attributes are shown in the window, arranged in a grid. The Tasks from ALL
the Pages and ALL the Subprocesses appear by default, but they can be filtered by Code, Page, Name or

Subprocess to reduce the list. The Filter field icon makes it possible to select the objects to be viewed.
Clicking on one of the tasks in the list will open a window from where the task’s attributes are configured.
This window will differ according to the type of Task, either a Personal Task (performed by a user) or a
System Task (performed by the system itself, without human intervention).
Consult the documentation on System Tasks for complete information about their configuration possibili-
ties.
We will now explain the configuration of the Personal tasks.
By clicking on a certain Task, a window will open in which the Type and the Name identifying the object
have already been created by the system.
By default, the Name shows the one indicated in the Diagram, but Multi-Language can be applied to it as
seen in the image below.
The Description shows the text introduced as such in the diagram object (in the following example this
field is blank). If the Text to Documentation field is filled in, this text will appear in the Class of Processes
Documentation (Descriptive and Detailed Document).
A different color can also be chosen for this task for when it appears in the Planning. Consult the docu-
mentation on Planning for more detailed information.
In order to give attributes to a Personal task, firstly define whether it is to be performed by an Employee,
an External User (through External Portals) or a Guest User (through the Public Website and/or via Email
or any other similar mechanism).
The window that appears on selecting the Performer and clicking Save, will differ according to the Per-
former:
1. Personal Task performed by an Employee
2. Personal Task performed by an External User
3. Personal task performed by a Guest User

3.3.1.1. Personal Task performed by an Employee
If the Task is going to be performed by an employee, the window for giving the attributes has the follow-
ing sections: EXECUTION (which includes Participants, Instructions and Workplace), CHRONOMETRICS
and CALENDAR VIEW.
Execution Panel
Firstly, the behavior of the task if the current arrives at it more than once is determined. This is called the
Cloning:

If Clone Enabled is selected, on each flow arrival the system will create a new task in all effects and it will be
included in the Comment Logs.
If Clone Disabled is selected, the same task will always be maintained. This case has the following particu-
larities:
• It does not accept Chronometrics.
• If the task is open, it does nothing.
• If the task has been terminated, when the flow arrives again it ‘wakes’ the task, keeping the Arrival
and Start date it originally had.
• If the performer has changed when the flow passes again, it acts as Clone Enabled, creating a new
TP with a different ID. If at any point the flow returns to the original performer, a new task will be
equally created, given that the performer will be different from the present one.
If the task must be performed by more than one user, its behavior must be determined:
• Task with Joint Execution = Yes. If the task has more than one performer, the flow will not contin-
ue until all performers have terminated their tasks.
• Task with Joint Execution = No. If the task has more than one performer, each terminated task will
generate a new flow to the next object.
EXECUTION PANEL - Participants
Here is where the users who will take part in the task are determined. The options are:
1. Responsible. If not indicated, the system will use the one indicated as Performer. Consult the
Functions of the Task Responsibles table in another chapter of this document for more details
about the functions.
2. Performer. The Employee who must perform the task.

3. Emergency. When a Performer finds them self in a situation they don’t know how to resolve, they
can click the Emergency button located in the action bar of the task and a pop-up window will
open including an Editor, for adding an explanatory text. After clicking on Send in the action bar,
the participant chosen in this field will receive a Notification Task. If no one is indicated, the sys-
tem by default will use the Responsible of the Class of Processes.
Performer and Emergency Substitutes can also be chosen.
Note.
The Performer Substitute is the one to perform the Task if the first Performer is Ab-
sent. The absence must be noted in their employee Record. The function of the Sub-
stitute is established as follows:
- When an employee user is absent, the process tasks (TP) that have not been
started (i.e. their Range is 0), will be visible from their Substitute’s task inbox.

- For the Substitute to be able to handle them, they must click the Reclaim
button within each task, which will make them the Holder of the tasks, for
all purposes.
- Until the Substitute reclaims them, both users (Holder and Substitute) will
see these tasks in their respective task inboxes. They will only disappear from
the Holder’s inbox when the Substitute reclaims them.
- Although an employee has Absent status, if they logon to AuraPortal they

can handle their tasks normally, except for those that have been reclaimed
by their Substitute.
The way of defining the Participants is practically the same. Here, as an example, the Appointed Task Per-
former is explained. By clicking on the configuration icon, the following window appears:
EMPLOYEE
Firstly, we can choose between:
• Actor - Direct. The Task is sent to the Employee selected in the options displayed below.
• Actor - Supervisor. The Task is sent to the Supervisor of the selected employee. When Supervisor
is selected, the Supervision Grade has to be chosen: 1=Immediate Supervisor, 2= 2nd Grade Su-
pervisor, 3= 3rd Grade Supervisor, etc.
Then, one of the following options is chosen as the performer:
Responsible of the Class of Task. Only if a responsible has been defined.
Start Message Creator. If you wish for the employee who created the start message to be the performer.

Employee. If the performer of this task must be a specific employee, by marking this box a new field will
appear on the right, and by clicking on the icon, a window pops-up for selecting the employee.
Role. If the task execution must be assigned to a specific Role, by marking this box, a new option appears
on the left, for defining whether the Role will be Singular or Generic, as shown in the following image:
• Singular. If this box is marked, clicking on the search icon will open a window where a previously
created singular Role can be selected or a new one created. This window is similar to the one that
opens for Generic Roles, shown below.
• Generic. By marking this box (1) and clicking on the icon, the following window will open to se-
lect the Generic Role:
Apart from this Role selection window, a new field also appears: Base Action Place (AP). Clicking
on the icon (2) will open a window with the Panel fields of the Class of Processes. The Base Ac-
tion Place is the Panel family field that will use the motor for defining the Generic Role and, there-
fore, its Assignee.
Note.
The Handling of Singular Roles is very simple but in Generic Roles it’s more com-

plex. In order to obtain a complete understanding, consult the information on
Roles, Profiles and Employee Groups.
Panel. The performer of a specific task can be someone that has been designated in a previous task by the
selection of an Employee from the Task Form.
Note.
For example, if designing a Class of Processes for Client Complaints, in which the
Customer Service responsible will determine who must solve the issue, it can act the
following way:
1. The task in which the responsible must select the user to solve the issue will have
an Employees Family field in its Form. This way, in Execution, every process of
this class will be solved by the relevant person(s).
2. In the Resolution task(s), the Panel box will be marked as Performer and the
Employees Family field of the previous point will be selected.
As this selection can be carried out by a General Field or a Group of Fields, by marking the box the selec-
tion of the field type appears on the right.
• If it’s a General Field, by marking this option and clicking on the search icon, the Panel shows the
compatible fields, which are the Employee, Prefix or Family fields or Text type fields. If various
employees are linked to a Family-Employee field, each one of them will receive a task, as if it
were a Parallel type Employees Group.
Note.
One of the possibilities allowed by the system is the use the Responsible Suffixes
from the Family Element Records as Personal Task Performers. This way, when an
Accounts, Projects, Items or Areas element has been selected in a Process, a later
Task can be automatically directed to its responsible.
• If it’s a Group of Fields, by marking this option and clicking on the search icon, a window pops-
up to select the container that will be used (this could be the Group of Fields itself) and the col-
umn that will be used as Addressee (Performer). It is also possible to configure whether the ad-
dressee will receive One Task per Line or a Unique Task for all the Lines of the Performer.
From Other Task. Lastly, the performer of a certain task can be the same performer of a previous one. In
this case, by marking this option and clicking on the search icon, the window for selecting the previous task
will open.
It is also possible to define whether dealing with the Appointed Performer of the Class (the one selected in
this window when designing the model) or the user that actually performed the previous task ( Real Per-
former of Task), as due to various circumstances they may different (it could be a substitute, for example).
The option: Assignment with Load Balancing makes it possible to apply this feature in Personal Process
Tasks to Employees that are in execution. It is only applied to Employee Groups with exclusive behavior
Not Delegable or Delegation: Discretional. When this option is set to Yes, the BPMS Motor will assign
the task to the user of the group that has the least pending tasks of this class in their workflow. In this sce-
nario, the user will not have to reclaim the task to be able to perform it.
Note.
The Absent users are excluded from the task distribution.

NOTIFICATION
Send Task by Email. This option allows the task to be received by Email. By marking Yes, the performer
defined in the previous box will automatically receive an Email when a task arrives in their workflow. From
that same Email, they will also be able to access and perform the task.
If the performer is absent, which is indicated in their personal Record, they will still receive the email and
so will the user acting as Substitute.
If Yes is selected, the configuration icon will become enabled, which leads to the following window to con-
figure the email:

The different options are explained below:
Email Address. To define the address where AuraPortal will send the email. It can be:
• Email Performer. By marking this box, the system will send the email to the address contained in
the record of the Employee defined as the task performer. It’s the usual.
• Panel. If the email address has been indicated in the Form of a previous task. By clicking on the
search icon that appears, the Panel shows the available fields.
• Manual. If wanting to indicate a fixed email address, which will be unique for all the processes of
this Class.
Number of Retries (Every 60 sc.). To indicate the retries that the system will attempt when encountering an
event that prevents the email from being sent.
Sender. In order to avoid using SPAM, the current mail servers do not permit sending an email in the name
of others. To avoid that this option affects the mail sending from AuraPortal, the sender of all these Emails
sent from Process and Open Task options, is now the one configured in Structure – GENERAL – Adminis-
trators – Email – Tasks – Email Sender. Here the sender appears to be consulted.
Email Subject. The ‘Subject’ that will be shown in the Email received by the user can be written in this field.
It will be fixed if Manual is selected, or it can be chosen in execution if a Panel field is chosen.
Reference. For indicating what should be displayed:
• The Base Reference. Made up of the Key, ID, Version Number and Order Number of the process
initiated from inside this Class. (This has been explained in detail at the beginning of this docu-
ment).

• The Extended Reference. Made up of the Base Reference, plus two Panel Fields from the ones
considered as Themes. This consideration will have been indicated from the Configure Field win-
dow when marking Yes in the field Theme. (Refer to the documentation about Dynamic Forms
for more details).
• Do not display. Neither of the two.
TEXT BODY. For creating the entry text, the performer will receive using the Editor (see the Data Source in
Guest User Tasks (Emails) section).
Note.
One of the advantages of this option is to receive a task reception notice via email
on mobile devices, such as a PDA.
Click on Edit to add text to the email. If Multi-Language is available, click on the Multi-Language configura-
tion icon to establish a specific message for each language available in AuraPortal.
COMPLEMENTS. With 3 options.
• No. The email will not include a document.

• Integrated. With this option selected one or several documents can be integrated which will be in-
cluded as text in the email.
• Panel. To select a Document Library field from the Panel. This way, the included documents will be
selected dynamically, in execution.
Note.
The Send Task by Email function becomes inactive if the corresponding option was
marked in Structure – Mail. See the image below:
Send Alert by SMS. This option allows 2 alternatives:
• Generic (TS-INVOKER of Web Services). Clicking on the configuration icon a System Task of this
type can be configured, which executes a Web Service, for example: to send SMS.

• Infoe.es (www.infoe.es). Clicking on the configuration icon, a notification SMS can be configured
using the provider: Infoe. More information can be found in the documentation about System
Tasks.
Note.
The Send Task by SMS function becomes inactive if the corresponding option was
marked in Structure – Mail (See the image in the previous Note).
By clicking on Save and Exit, the performer of this Task will be registered.
Send Message to ‘Instant Workflow’ App for mobiles.

The Instant Workflow functionality is based on an App that sends an instant notification to the mobile
device of Employee or External users of AuraPortal when they receive a task (configured with this option) in
their workflow. From the received notification, they can open and deal with the task. For example, the
maintenance supervisors of a Server center could receive a notification when the temperature of the center
rises above 30ºC.
For a task to be able to notify of its arrival via the Instant Workflow App, two steps must be followed:
1. Install the Instant Workflow App on the mobile device of the user who wants to receive the notifica-
tion.
The “Instant Workflow” App is available for Android and iOS systems and can be downloaded from the
Google Play Store or the Apple Store, writing Instant Workflow in the search box. It is also possible to
access the stores using a QR Code reader on the following code:
Once the App has been downloaded on the mobile device, the user must authenticate themselves with
their AuraPortal credentials. See the image below:

Write the URL of the AuraPortal installation, the User and Password and click CONNECT. When the user
registers, the Settings screen will appear:

Here there are two panels:
Default Screen panel. This shows the 3 features that are available in the Instant Workflow App:
• My Tasks. This shows the connected employee’s My Tasks grid.

• Notifications. This shows the notifications received by the employee because they are the recipi-
ent of a TS NOTIFIER (Notifies “Instant Workflow” App for Cell Phones) or they are the Performer
of a Personal Task which has been configured with Send Message to “Instant Workflow” App for
Cell Phones = Yes.
• Subscriptions. Shows the Titles of the NOTIFIER System Task (Notifies “Instant Workflow” App for
Cell Phones) in which the employee figures as a recipient because they belong to the configured
Role.
Note.
For more information about the App associated to the TS-NOTIFIER (Notifies “In-
stant Workflow” App for Cell Phones), consult the corresponding documentation.
Mark the desired default screen. Firstly, Notifications, to see the notifications directly on accessing the
App.
Options panel. With three alternatives:
• Keep completed tasks. With this option marked, received notifications will not be deleted, even
though the task that generated them is terminated. This option is only applicable with the TPs.
• Receive notifications. Unmark this option if you don’t want to receive notifications.
• Silence. Mark this option if you don’t wish to hear a warning tone when notifications arrive.
The light blue triangle that appears in the image above indicates that a submenu will open from left to
right; see below:

This gives access to the different screens (1), information about AuraPortal from the About button (2)
and a Disconnect option (3), which deletes the introduced credentials so that the user will not receive any
more notifications.
Clicking on Notifications will open the employee’s notifications, received either by TS or by TP. The screen
will look like the following:

Note.
The image above shows that the Notifications are grouped into: Today, Yesterday
and Older. If the Keep completed tasks option has been marked, another section,
Terminated, will appear at the bottom of the screen, which groups the notifica-
tions whose TPs have been terminated.
There are three tabs in the Notifications screen:
To view ALL the notification together, just those from TP or just those from TS.
The image below shows an example of a notification:
Clicking the OPEN TASK button will open the task for it to be dealt with.
2. Configure the Task in the NOTIFICATION panel of the Task Performer section. See the following im-
age:

The search icon opens the following configuration window.

Choose the desired title for the Notification in the TITLE panel (1). A compatible Panel field can be chosen
or a Manual text with Multiple-Language. The image above shows the configuration of this field and the
one below its execution.
The Notification content can be added in the CONTENT panel (2) with Multiple-Language. The image
above shows the configuration of this field and the one below its execution.
In the OPTIONS panel (3) it is possible to parameterize the way in which he Notification will be managed
by the App on the mobile device.
The Cell Phone Warning field allows us to choose whether the tone will be Notification, Call or Alarm. The
choice will probably depend on how critical the Notification is.
Note.
The Call, Alarm and Notification tones are the ones configured by the user on their
mobile device.
The MESSAGE REPETITION panel appears when Yes is marked (4). Here it possible to indicate the Unit
that will be evaluated for the repetition: Days, Hours or Minutes. The number of Units can be determined
Manually (fixed) or it can be variable, taken from a Panel field.
Note.
The Units that are accounted for are natural units.
In the STOP REPETITION panel (5) we can indicate if the repetitions should be stopped On starting Task,
that is, when it is accessed, On terminating Task, when it has already been dealt with, or select one of both
options marking Panel, in which case a Yes/No field can be chosen and one of the two values selected in
execution. If Yes is chosen, the repetition will stop on starting. If No, it will stop on terminating.
Note 1.
The same configuration page is available for Personal Tasks to External Users.
Note 2.
The General Impersonation must be configured for the App to work correctly,
from Structure-Settings-Impersonation.

EXECUTION PANEL - Instructions
The Instructions the Task Performer will see in his screen can be as complete as desired and they may con-
tain not only enriched text, but also images, backgrounds, tables, sound videos, etc. All this is possible
using the powerful AuraPortal Editor which is described in the documentation available about Dynamic
Forms.
They can have the following formats:
• Text. If text is marked, by clicking on the Edit button the AuraPortal editor window appears, where
the Instructions text is entered: a textual explanation with the steps and actions to follow. What is
written here stays integrated in the Class of Task and will stay the same, although it can be modi-
fied from here in the future.
• Rule. If the instructions are not fixed but depend on certain circumstances, the Business Rules
containing these instructions can be specified here. These Rules, of textual nature, contain the ex-
planations of the steps to follow. At any moment the content of a Rule can change (regardless of
the Processes) and this will affect all tasks whose Instructions are based on this Rule.
• Panel. This case is for when the instructions for carrying the task (or part of them) are defined by
the performer of a previous task of the same process. These instructions will have to be entered in
a Text field, which is the one that should be selected here.
The Instructions may also be combinations of Fixed Text + Rule + Panel.
Note.
Apart from these general instructions (for the whole task), when designing the task,
specific instructions can also be created for a specific action or a group of actions
that must be carried out only under certain circumstances.
These instructions are normally created using Complements and they can be de-
signed to be activated automatically when the task performer finds it necessary.
EXECUTION PANEL - Workplace
Here the environment that the performer will find when they open the task is determined.

If Predefined Format (1) is marked, clicking on the search icon will open the list of existing formats, which
are called TEWs (Task Execution Windows). It is also possible to create new formats.
They are innumerable possible Execution Window formats to the user’s taste, combining the distributions,
sizes, relative positions and colors of each box that contains the Instructions, Forms and Comment Logs.
Each model record has a Viewer icon which opens the configuration in read-only mode. Click on the cho-
sen model to select it. To create a new model, click on the Create button in the action bar. All details about
format creation can be consulted in the Delegated Administrator Manual.
If Indicate Size in Form (2) is marked instead of choosing a TEW, only the form will be used. There is an
option called Size in the form design window, shown in the image below, where the Size and Position of
the window is configured.

Forms (3)
If the Task needs to contain one or more Forms to be filled in by the Performer, they are created here. For
this, by marking the Forms box and clicking on the configuration icon, a window pops-up to choose
whether to create an Original Form or select a Similar to other already available. In this case, which will be
the most common, by selecting a form the system creates a copy of this, to be modified.
Note.
When designing Forms, a minimum screen resolution of 1280x1024 must be used.
The Form design is explained in the documentation available about Dynamic Forms.
Comment Logs (4)
The Comment Logs of a Process contain who has taken part in each task, when they did so and the com-
ments added by the successive participants. For each Class of Processes as many Comment Logs can be
created as desired so that they act only in certain tasks. This way, only the relevant information will be
available to each user. So, from this field, for each Task the access to certain Comment Logs or others is
defined.
To determine the Comment Logs that will act in this task, by marking Yes and clicking on the configuration
icon, a new window will open where, clicking on Aggregate Comment Log, will open another window like
the one below:
From this window the comment logs that have to act in this task are marked. They must have been created
previously. After marking them and clicking on Accept Selection they stay in the first window for future
consulting.
From any Personal task Class to be performed by an Employee or an External User (not the same for Guest
Users), the Comment Logs are created in this window by clicking on the button Create Comment Log. It is
also possible to create them from the Comment Logs option in the EXECUTION panel in the general Class
of Processes configuration window.
Creating a Comment Log is simply giving it a Name. Once created, it stays available to be selected from
the classes of task of the same Class of Processes.

Chronometrics Panel
Besides the general Class of Processes Chronometrics, Chronometrics can also be defined for each Class of
Personal task. The operative is similar to the one explained above for the Class of Processes.
Calendar. Can be the same Calendar as the one generally defined for the Class of Processes, or a particular
one for this Class of Processes.
Duration. By marking Yes and then clicking on the configuration icon, the window that appears is for indi-
cating the duration parameters: Expected, Minimum and Maximum for the Tasks of this Class.
Update Planning Original Forecast. If you select Yes, the planning dates will be filled in when the flow
reaches the task, as follows:
• ORIGINAL FORECAST START. This will be filled in with the date-time the task arrives in the per-
former’s workflow.
• ORIGINAL FORECAST END. This will be filled in with the maximum date established in the config-
uration of the Task Control by Duration.
Calendar View Panel
The Calendar View provides the employees with an easy and graphic way to identify and control their
tasks that have a Forecast Date for their completion. The Calendar View clearly differentiates the tasks
whose dates have not yet been reached from those whose dates have already been reached or exceeded.
Personal Process Tasks show the Calendar View if configured for that purpose, using this section and the
consequent Date-Time fields such as Start Date and End Date. This way, performers can see their tasks in
Calendar format in their workflow.
The documentation about the Calendar View covers all the details of this functionality.

In the example image, two respective panel fields have been selected in the Start Date (1) and End Date
(2) fields: 3_Date from and 3_Date to. These fields will acquire their value in execution and will provide
the information for the Calendar View.
The Allow object to be moved with the mouse from Calendar View marker (3) marked as Yes will make it
possible to move the appointment directly from one point in the Calendar View to another, automatically
updating the Date-Time without having to open the form.
Note.
If the dates shouldn’t be modified, this option must be marked as No, and the fields
inside the form configured as read-only.
This will allow each employee to control their Tasks of a certain class in their Calendar View, and the fields
in the View will have the value that they have in the Panel at the moment they are displayed. This must be
taken into account given that if the Start and End fields are included as editable in any other part of the
process, they will be susceptible to being modified, which would also change the performer’s Calendar
View.
Note.
If the Start Date field has no value, the system will consider it as half an hour be-
fore the End Date, and if the End Date has not value, the system will consider it as
half an hour after the Start Date.
3.3.1.2. Personal Task performed by an External User
The External User is the one who communicates through External Portals. The operative is similar to the
one explained previously for Tasks performed by Employees, with the only difference being the Partici-
pants:

It is not possible to assign Substitutes in the External User tasks, but it is possible to select the performer
based on Account Profiles and Roles Profiles. The Account Profiles decide which accounts will receive the
task (Conditions can be applied) and the Roles Profiles filter the Roles of these account that will receive it.
For more information about the configuration of Account and Role Profiles, refer to the documentation on
Profiles, Roles and Employee Groups.
3.3.1.3. Personal Task performed by a Guest User
The Guest User is the one who communicates through the Public Web, the Guests Portal and/or via Email,
Process or other similar mechanisms. It contains the following differentiating fields:
Task with Joint Execution = Yes. If the performer of this task is more than one user, the task will not resume
the current thread until each performer has terminated their task.
Task with Joint Execution = No. If the performer is more than one user, each terminated task will generate a
new current thread leading to the following object.
Sender. In order to avoid using SPAM, the current mail servers do not permit sending an email in the name
of others. To avoid that this option affects the mail sending from AuraPortal, the sender of all these Emails
sent from Process and Open Task options, is now the one configured in Structure – GENERAL – Adminis-
trators – Email – Tasks – Email Sender.
Performer. The options are the same as for the External User: Start Message Creator, Account Profiles/Role
Profiles and Panel.
Form. Form design is explained in the documentation available about Dynamic Forms.
Inform by Email. The Guest Users can access their tasks in two ways:
• Via the Guests Portal. More information can be found in the documentation available about the
Guests Portal.
• Inform by Email. In this case, AuraPortal automatically creates and sends an Email to the Guest Us-
er. This email contains a link and, after entering their Login and Password, the Guest User can ac-
cess their task.
If the Inform by Email option is marked as Yes, the following fields will appear in the window:

Number of Retries (Every 60 sc.). To indicate the retries that the system will attempt when encountering an
event that prevents the email from being sent.
Email Subject. The ‘Subject’ that will be shown in the Email received by the Guest User can be indicated in
this field. Either a Panel field can be chosen or Manual text can be introduced, which Multi-Language can be
applied to.
Reference. For indicating what should be displayed:
The Base Reference. Made up of the Key, ID, Version Number and Order Number of the process initiated
from inside this Class.
The Extended Reference. Made up of the Base Reference, plus two Panel Fields from the ones considered
as Themes. This consideration will have been indicated from the Configure Field window when marking
Yes in the field Theme.
Do not display. Neither of the two.
Text Body. By clicking on the Edit button, the AuraPortal Editor will open. Here the Email text can be creat-
ed, where Panel fields (as many as desired) can also be introduced. The operative with the Editor is ex-
plained in the documentation about Dynamic Forms. Multi-Language can be applied.
Note 1.
Once inside the Editor, there is a particularity in the Data Source icon in the case of
Guest User Tasks, which is the possibility of adding a link to the TP form with or
without a request for credentials. If the Form (no credentials request) option is
chosen, the user can open the task without being asked to provide a login and
password.
Note 2.
In regard to the behaviour of the Task arrival to Guest Users, the following must be
taken into account:
1. Each time the current passes through the same Guest User Task, the exist-
ing task will be restarted and its status will change to Arrived; no new task
will be created. If it is dormant, it will wake up. In other words, it is Clone
Disabled.
2. Each time the current passes through, the user will receive a new notifica-
tion by email.

3. The status shown in the tracking when the current has passed through the
task more than once, is Reactivated.
3.3.1.4. Functions of the Task Responsibles
The employees that are Responsible for the Classes of Processes, each individual Process and each Class
of Task, will receive several communications that are important to the smooth running and development
of the processes.
The following tables show a relation of these functions and the type of information each responsible will
receive.
RESPONSIBLE OF THE CLASS OF TASK

the task.
SUBSTITUTE (Both as Performer They will receive the task if the

of the TP and of the Emergency). performer is absent or the emer-
[Definable]. gency notification if the owner is
not available.
TS-NOTIFIER to Employees and RECIPIENT (as “Real Performer of They will appear as the sender of
External Users the Task” if the Recipient were the notification.
the Substitute = Responsible of
the Class of Task). [Definable].
3.3.2. Events
The Events tab (1) shows the Classes of Events to which attributes must be given. By default, all the Clas-
ses appear. To limit them, click on the Filter icon to open the window to select the desired classes. Then
click on Proceed.

Clicking on a certain event (2) will open another window, which will differ depending on whether it is a
Start Message Event, an Intermediate Event or a Start Time Event. The Start Time Events start processes
at a specific indicated moment, such as a complete date, or a year, month, week, day, hour or minute. The
Start Message Events start processes when an event occurs that can be identified with a notification or a
message. This type of event is activated when:
1. A form is executed.
2. Specific information is received via Web Services.
3. An order arrives from the AuraPortal ‘Online Commerce.’
3.3.2.1. Start Message Events
Clicking on the Start Message will open a window with the following sections:
• IDENTITY
• BEHAVIOR
• CALENDAR VIEW (Only in Messages for Employees)
• PRESENTATION IN EXTERNAL PORTALS (Only in Messages for External Users)
• PRESENTATION IN GUEST PORTALS (Only in Messages for Guest Users)

In the IDENTITY section, the Event Type and the Name given to the event while drawing the Diagram al-
ready appear. The Description box will show the text introduced as such in the diagram object (in the im-
age above this box is empty). If the Text to Documentation field is filled in, the introduced text will appear
in the Documentation of the Class of Processes (Descriptive and Detailed Documents).
The BEHAVIOR section, the ACTIVATED BY panel includes the following fields:
Form. If this option is not selected, it will not be possible to activate the event with a form, it will only be
possible to invoke it through a Deviator System Task or from an external program.
Note.
The combination: Web Services = selected + Form = unselected means that the
Web Service will not be available to be introduced manually.
By clicking on the Form icon, the Form Creation window will appear where the Start Message form (IM)
can be designed.

The form design is explained in full in the documentation available about Dynamic Forms. The Multi-
Language field in the image above is related to the name of the form.
Web Services. This is unselected by default. Select it and click Save to access the Web Service configuration
window in the Start Message. The following window will appear on clicking the configuration icon:
Configure the options as follows:
Web Service Name. This will be the name the Web Service will be published with. With this name a .asmx
page (entry to the Web Service) will be created in the \WS folder of the website where AuraPortal is in-
stalled. This name does not need to coincide with the name of the Message Event Form it belongs to.
Description. The Description is optional.
URL. This field appears below the description when the Web Services is created and is filled in automatical-
ly with its location. The path is always the same, for example:
http://obtenida.portal.local/WS/WebServiceName.asmx,
This URL is made up of the following:
obtenida.portal.local depends on each installation
WebServiceName.asmx depends on the name given to the Web Service, in this example _Joker_MI.asmx
If Impersonation has been configured for Web Services (from Structure – Settings – Impersonation), it
will be created in the indicated folder and can be consulted from the browser.

In this Web Service entry window just one method will be seen, with the same name that has been given to
the Web Service but preceded by an underscore, in this case _Joker_MI.
Clicking on the method will reveal just one generic parameter, named Datos:
If this window has been opened from the AuraPortal server, the parameter will appear as in the image, i.e.,
allowing manual introduction for testing purposes. However, if it is opened from another computer that is
not the server, the SOAP data will be displayed but not the Datos parameter for manual introduction. The
following message will appear in its place: The testing form is only available for requests from the local
computer.
Note.
Once a Message Event has been published as a Web Service, not only can it be used
from DEVIATOR System Tasks, it can also be invoked from external programs.
It is very easy to make a program to invoke these Web Services with .NET, Visual
Basic, etc. (AuraPortal provides programming examples with the source code in-
cluded).

Online Commerce. This is unselected by default. If it is selected, you will be able to choose it from the
Transfer to Process option in the configuration of the Shopping Cart. All information about the AuraPortal
Online Commerce can be found in the documentation on Content Management and Online Commerce.
Access URL. The Start Message URL will be shown on clicking on the icon. Therefore, if you want the Start
Message to be performed from anywhere, just copy this URL. For example, so that Guest or Anonymous
Users can initiate processes from the public Website (or from any other place).
Default Data. Clicking on the configuration icon will lead to a window showing only the action bar:
The fields that are added to this window, with or without values, will appear by default in all the Start Mes-
sages of this Class of Processes.
Click on Aggregate Fields to add fields (from the process panel) to the window. The following image shows
the Family-Accounts field:
The value is added to each field according to its identity. If the field is a family field, like in the image, click
on the configuration icon to add the default accounts.
Successively add all the desired fields.
Then click on Fields Configuration to delete (1) previously added fields or to establish the order (2) in
which the fields will appear in the window:

Click the Integrate Doc from Library button to include documents integrated in Libraries in SharePoint in
Library in Dictionary fields. See the image below:
Clicking on the Aggregate Upload from Library button will open the window below, where the documents
to be included as default data are configured:
Give a Name to the upload being configured (1). Click on the Origin Library search icon (2) and select the
desired option in the Upload field (3), depending on whether you would like to include All documents in
the library or just a Selection of them. Click Save (4).
The Aggregate Destination Library Field button will become active, which leads to the following window:

In the Destination Li. Field (1), Indicate the Library field in the panel where the documents will be saved
(the only active option).
The Details of uploader (2) are the details used to impersonate the upload. They must have the necessary
permissions to access the configured Library in SharePoint. Click on the Test button (4) to check that the
selected user is suitable.
Once you have clicked Save in the actions bar, the Conditions field (3) will appear, where the conditions
for performing the upload are configured.
In the CALENDAR VIEW section, the Start Date and End Date fields are configured that will be used so that
the Start Messages in Draft status can be seen in the Calendar format of the Start Message Creator’s My
Tasks Grid. This section only appears when the User chosen in the Start Form is an Employee.
Note.
See a summary of this feature in the Personal Task performed by an Employee
section further up in this document, and the complete information in the specific
documentation available about the Calendar View.
In the PRESENTATION IN GUEST PORTAL / EXTERNAL PORTAL there is an option to indicate whether
the Start Message will be visible from the corresponding Portal or not. If No is selected, the Message will
only be available directly from its URL.
There is an option in the Guests Portal that is not available in the External Portal; the Presentation Text
field, which opens the text editor where a more detailed presentation can be introduced. It is Multi-
Language.

3.3.2.2. Start Time Events
A Time Event (ET), either at the beginning of a Process or an Intermediate Event, allows the flow to contin-
ue when the time condition (date and time or duration) established when defining its chronometrics is
fulfilled. The IDENTITY section is the same as explained for the IM, but in this case the Event CHRONO-
METRICS must be defined:
Note.
As the process has not yet started, with the Start Time Events the only option is the
Control by Date.
Calendar. To choose either the Calendar that has been defined for the Class of Processes, or a particular
one for this Class of Event.
Event Clock. To choose between the Process Clock (the same clock as the one used for the Process), or the
server Clock or local Clock.
Control by Date. Choose this option when you want the system to allow the flow to pass at a specific mo-
ment, which must be defined here.

Note.
In the Start Time Events, as the process has not been started there are no data in
the Panel, therefore it is only possible to choose Modality.
It can be defined in two ways:
Panel. On selecting this option, two new options will appear:
Dynamic (it reads the Panel date every minute. This option is the slower of the two). With this option the
BPMS Motor resolves the value of the panel field every time it reviews the events, once a minute.
Unique (it only reads the Panel date once. It is the quicker of the two). The BPMS Motor applies the value
that was in the panel when the flow reached the Event.
If the panel field has no value, it behaves as Dynamic, i.e., the BPMS Motor checks the Panel every
minute until it finds a date to save.
On clicking the icon, the Class of Panel window will open showing the Date fields, to select the one that
should set the moment in which the flow is allowed through.
Modality. By marking this box, the Date modality can be chosen. Once chosen, clicking on the configuration
icon will open a window with the fields for selecting the moment in which the flow is allowed through.

If Control by Hours (1) is set to Yes, by clicking on the configuration icon, a window will open to indicate
the time interval in which the event has to act.
The If holiday, substitute with: field indicates what the system should do when the event is to be executed
on a holiday. The options differ slightly depending on whether it is a Start or Intermediate Event.
The options for the Start Event are the following:
If No Substitution is selected, the process will start even though it is a holiday.
If Do not start Process is selected, when the date falls on a holiday, the IT execution will be ignored, pre-
venting a process from being started on each holiday until the next working day.
If Following Working day is selected, the event will execute on the next working day after the holiday.
If Manual Date is chosen, a date field will appear to select a specific date.
The options for the Intermediate Event are the following:
The ignore option is not available and Date in Panel appears. As the process in this case is already
running, a Panel field can be defined to set the substitution date dynamically.

Control by Duration. When desired that the system allows the flow to pass after a certain time period. It is
defined in the fields of the following window:
Unit. Firstly, the duration unit must be defined, choosing between Days, Hours, Minutes and Seconds,
Working or Natural (calculated using the Calendar chosen in the first question).
Count from. Next, the beginning of the duration is defined. It can be the moment the flow arrives to the
Event itself, or Other Position. In the second case, on selecting between the options given the system
allows choosing the desired element.
Control by. With two options:
Calendar days (Processing speed is increased). This is the default option. The event matures at the start of
the day, i.e., it does not wait 24 hours, so this type of event is evaluated once a day.
24 hour periods. The events are evaluated every hour, which uses up more resources.
This section is only available when the Units of the Time Event are Days, either Natural or Working.
• Value. Finally, the duration is determined. It can be defined as a Numeric Panel field, or by directly
entering a Manual value.
If you select Panel, two new options will appear:
o Dynamic (it reads the Panel date every minute. This option is the slower of the two). With
this option the BPMS Motor resolves the value of the panel field every time it reviews the
events, once a minute.
o Unique (it only reads the Panel date once. It is the quicker of the two). The BPMS Motor
applies the value that was in the panel when the flow reached the Event.
If the panel field has no value, it behaves as Dynamic, i.e., the BPMS Motor checks the Panel every
minute until it finds a date to save.

3.3.2.3. Intermediate Message Events
The Intermediate Message Event (EM) is similar to the Start Message event; the IDENTITY and CALENDAR
VIEW sections are the same as those explained for the IM. The different sections are explained below:
The BEHAVIOR section:
The ACTIVATED BY panel includes the following fields:
Pattern. An EM can use its own Form or a Pattern, which is a form that can be used in many Processes.
Note.
A Pattern is created from Structure – Processes – Environment - Patterns. There
the pattern is created and then dictionary terms are introduced as in any other
form, but no design is carried out.
Inside the pattern there’s an obligatory field that, on creating the pattern is put
there by default and is called ‘_Process Reference List’. It is used in an Intermedi-
ate Message Event for choosing the Process that has the flow detained in that spe-
cific EM.
This field can also be placed in the form of a Personal task for choosing whichever
process in execution, not only those detained in an EM as in the previous case. This
option is very useful for selecting one process from another one, for example for be-
ing able to make a diversion at another point of the diagram.
• If Pattern = Yes is marked, by clicking on the search icon a window pops-up for selecting one of
the patterns already created from the Patterns tab (Structure – Processes – Environment).
• If Pattern = No is marked, the Form field will appear.
Form. If this option is not selected, it will not be possible to activate the event with a form, it will only be
possible to invoke it through a Deviator System Task or from an external program.
Note.
The combination: Web Services = selected + Form = unselected means that the
Web Service will not be available to be introduced manually.
Clicking on the icon, another window pops-up to choose whether the form will be Original or Similar to
another which is already available. In that case, which will be the most common, by selecting a form the
system creates a copy of the chosen form, in order to be modified.
The Forms design is explained in the documentation available about Dynamic Forms.

Conditions. Moreover, in order to filter the processes seen from an Intermediate Message Event (EM), the
Conditions option is available (whose operative is similar to the one explained in the Gateways section, or
in more detail in the documentation about Dynamic Forms).
By clicking on the icon, the window for adding Conditions pops-up. Pressing the Create Conditions button,
in the REAL DATA section the Condition with – Filter by Performer option appears:
As Source, the only available option is Panel, where any type of Panel field that may have a Performer can
be chosen (Prefixes and Family of Employees fields, Start Message Author, Suffix Responsible, etc.).
This way, if in the configuration of an EM the Start Message creator has been selected as Filter by Perform-
er, for example, when a user goes to create the EM, only the processes where they were the Start Message
Creator will appear in the List of References field. As another example, a user will only see the EMs where
they have been selected in a particular Family or Prefix field.
This Filter by Performer is available for Employees and External Users.
Web Services. This is unselected by default. This feature has already been explained in the Start Message
section.
Access URL. This displays the URL to access the EM, to enable messages to be created from anywhere.
Note.
Filter parameters can be transferred through the URL to the Intermediate Event
search window, specifically to the page called
BPM_ProcesosReferencia_Buscador.aspx
The accepted parameters are the following:

•Theme1
•Theme2
•ProcessReference
•StartDateFrom (AAAA-MM-DD HH:MM)
•StartDateTo (AAAA-MM-DD HH:MM)
In the last two, the hours and minutes (HH:MM) are not necessary.
Example of complete URL with parameters:

http://intranet.auraportal.net/Home/BPM_ProcesosReferencia_Buscador.aspx?idg=2
3&id=107&idform=2202&pag=107&Datos=[[[Theme2:::Empresa]]][[[Theme1:::Con
tacto]]][[[StartDateFrom:::2015-06-27 13:56]]][[[StartDateTo:::2015-06-27]]]
Multi-Language. The language of the EM can be configured if you have the Multi-Language module in-
stalled.
EVENT Section
See the image below:
Without Reactivation. When the flow arrives at this event, data entry will remain active until the first mes-
sage is created. It will not become available again until new flows arrive from the workflow.
Automatic Reactivation. When the flow arrives, unlimited messages can be created to introduce infor-
mation in the process. This way, it is not necessary to create a loop to return the current to the EM when
you want new data to be continuously introduced in the process, for example when receiving successive
deviations from other processes via the TS-DEVIATOR. Thus, the EM can receive entries simultaneously
improving performance.
With the Automatic Reactivation option, once the flow arrives at the EM, it remains permanently active until
one of the following possibilities occur:
• There is a CX Gateway after the EM which is terminated due to the completion of another object
other than the EM.
• The EM is inside a Subprocess that reaches its End.
• The Process is terminated.
Note.
When the EM is configured with Automatic Reactivation, each user will only see
the EMs that have been blocked by them, not by others, in the Intermediate Event
search window.

3.3.3. Gateways
By clicking on the Gateways tab, the Gateways to which the attributes must be given are shown in the
window.
The gateways appear in the grid. Those that have already been configured are marked with a .
The gateways can be filtered by Code, Name, Page or Subprocess. By default, the gateways of All the pag-
es and All the Subprocesses are displayed. To limit the gateways that appear in the grid, use the Filter
search icon.
Only the Divergent DX and DO gateways require configuration. Click on one of the Gateways to configure
its outlets. The window will look something like this:

Note.
An appendix at the end of this document explains the different types of Gateway
and their behaviors.
IDENTITY. The Type and the Name that identify the gateway have already been created by the system. A
Description can also be added.
BEHAVIOR. On entering, the window already shows the different Gateway outlets with their data, as they
have been defined in the Class of Processes Diagram.
Note.
The DX Gateways, as seen in the image example, contain a Default Outlet that
always allows the flow to continue when the rest of the exits don’t meet the condi-
tions. This guarantees that the flow won’t stay blocked in the Gateway.
The marker indicates that the gateway conditions have been configured.
The following can be defined for each outlet: a Description (optional) and the Conditions the outlet must
meet for the current to flow through it (explained further on).
Note.
It’s not mandatory for the Outlets to have Conditions. The unconditioned Gateways
always allow the flow to continue.

Also, if there is more than one outlet, the Evaluation Order in which the Motor must evaluate the condi-
tions of each outlet must be indicated. When one Outlet meets the conditions, the current redirects
through it and the rest will not be evaluated. So, in cases where the Outlet preferences differ, the evalua-
tion order from the highest to the lowest rank is very important.
Conditions
By clicking on the icon, the following window opens:
Using the Create Conditions button (1) the conditions are created and placed in the list below (2) to be
consulted. If more than one condition has been created, the Logic Operator (3) to be applied must be
selected: AND (if all must be met), OR (some) or XOR (only one).
In the image example, the system will send the flow through the Yes outlet when the Total Price of the
Purchase is greater than or equal to 300€.
By clicking on the Create Conditions button, a window opens for defining the Panel field that determines
the gateway condition. The rest of the window will be different according to the selected field, although
following the same criteria and operatives. In general, on the selected Panel Field, a Comparison Pattern is
defined, which can be conditioned to certain Comparison criteria.
Note.
Details about the configuration of Conditions and Sets can be found in the docu-
mentation about Dynamic Forms.

As seen in the example of the previous image, when the process flow arrives at the ‘Needs second Approv-
al?’ gateway, if the ‘Total Price’ field of the purchase is Greater than or Equal to 300€, the system will send
the flow through the Yes outlet.
CHRONOMETRICS. The following options are available to define the Chronometry:
• Calendar. To choose either the Calendar that has been defined for the Class of Processes, or a par-
ticular one for this Gateway.
• Gateway Clock. To choose between the Process Clock (the same clock as the one used for the
Process), or the server Clock or local Clock.
The gateway behavior will be defined on clicking on Save and Exit.
3.4. Spans
The Spans are time intervals, defined as the temporal distance between two Points of Control (which
control the passing of the flow through a certain point). The Model designer can insert to the Diagram as
many Points of Control as he wants and define the Spans he needs for analyzing the time behavior of spe-
cific portions of the Processes. The Spans are very useful in Tracking.
Click on the Spans tab (1) to access them. The Points of Control are configured and the Spans are created
from this window.

To access the Spans, click on the relevant tab (1). Spans are created in this window and the Points of Con-
trol configured.
The upper panel (2) contains the following data:
Name. The name of the Span.
Description of Itinerary. A Rich Text field that includes the icon resembling a palm tree for choosing Panel
Fields when customizing the description. This text will be shown as an Explanation of the Span on clicking
the Status button, which is available for monitoring the started processes by Employees, External and
Guest Users. Depending on the Portal, the Status button is located in different places:
Employees Portal (My Messages Status button in the actions bar of My Process Tasks):
External Portals (My Message Status button in the actions bar of My Tasks):

Guest Portals (in the example below, the My Requests button, designed with the AuraPortal Content Man-
agement).
Multi-Language. To apply Multi-Language to the Span.
Using the Spans, the Points of Control which the processes initiated by the user have passed through can
be seen (for example if a request has already been approved), and the Description of Itinerary of the Spans.

On entering the window for the first time, in the grid (3) appear only the Points of Control included in the
Diagram.
1. Configuring the Points of Control

By clicking on a Point of Control in the grid (3), the following window will open:

The IDENTITY panel contains the Name and Type of the Object, obtained from the diagram itself. The De-
scription shows the text introduced as such in the diagram object (in the previous example this field is
blank). If the Text to Documentation field is filled in, this text will appear in the Documentation of the Class
of Processes (Descriptive and Detailed Documents).
In the PROCESS STATUS panel there are three fields:
Status. For indicating the name of the WIP Status button.
Description. Rich Text that includes the ‘palm tree’ icon for choosing panel fields.

Multi-Language. For indicating the button name in the different languages.
To define the BEHAVIOR of a Point of Control, the following must be established:
Critical Level. For choosing the control importance. Later on, Tracking can carry out the controls depending
on the Critical Level.
Expected/ Minimum/Maximum date. For defining the range of the control. In the case of Points of Control of
Expected, Minimum or Maximum duration, it’s defined only using a panel field.
Alerts and Alarms. It is activated only if controlling a Maximum duration.
Unit. The duration of the process execution can be defined in Days, Hours, Minutes and Seconds, both
Natural and Working ones (measured using the Calendar indicated in the first question).
Alert – Alarm. If Yes is marked, the two following fields are activated:
Notifying Message to. To choose the users that should be warned if the Alert or Alarm is triggered. These
users will automatically receive a Notification Task when the Alert and the Alarm are triggered. The op-
tions available are: Responsible of the Class of Processes, Process Responsible, Employee, Role and Panel.
Alert Threshold. For defining when the Alert should be triggered:
An Alarm is triggered when the Maximum duration established is reached.
An Alert is triggered when the Alert Threshold established is reached.
To define the CHRONOMETRICS of a Point of Control, the following must be determined:
Calendar. It is possible to choose between the same Calendar generally defined for the Class of Processes
or a particular one for this Point of Control.
Clock. Either the Process Clock (this implicates using the same Clock as the one generally used for the Pro-
cess), or directly the server Clock or a local Clock.
2. Creating Spans
Every Span has an initial Point of Control and an end Point of Control. To create a Span, click on the Create
Span option in the action bar:

A window will pop-up where a Name and Description can be introduced. Next, click on the Save button to
open a new window like the one below:
Here you can:
− Select the Initial Point of Control (which can be the Beginning of the Process or a Point of Control)
and the Final Point of Control (which can also be the End of the Process).
− Define the Chronometrics, which is similar to the mechanism already explained for the Tasks and
other objects.

The Spans created this way stay in the grid of the main window. Their codes are generated automatically,
combining the codes (without the names) of the Initial Point of Control (the IM in the image below) and
the Final Point of Control (the K1 Point of Control in the image below) that delimit them.
Generating Alerts and Alarms, those involved can control the duration of the Spans, that is, how long it
takes to perform all or part of the process.
In the image below we can see an example of a Span on the left, and the initial and final points indicated in
the diagram on the right.
3.5. Base Documents

Base Documents is an AuraPortal functionality, which permits preparing documents that will serve as a
pattern for the creation of Automatic Documents along with the variable data of each Process.
For the Base Documents design, two different editors can be used: MS Word, Versions
2003/2007/2010/2013 and HTML, which, being included in AuraPortal, doesn’t need any additional soft-
ware. If complex documents are desired, it’s normally recommended using MS Word.
Once the Base Document has been designed, it can be performed in two ways:
− From a Button in a Form of a Task or a Start/Intermediate Message. The Automatic Documents

will be created when the user clicks on the button. If he has permissions, he will be able to modify
them before creating them.
− From a System Task. The Automatic Documents will be automatically created when the workflow
current passes through it, with no user intervention. For this, a ‘Create Base Document’ type Up-
loader System Task, must be used and configured.
In both cases the document created is automatically saved in the destinations chosen when configuring
them. These destinations can be:

− Integrated in a Library Field.
− Uploaded in an AuraPortal Library and associated to a Library Field.
− Both the previous at the same time, which will duplicate the document.
To create a Base Document, click on the Base Document tab, which included five options, as can be seen
in the image below:
The Base Documents are created from the first option. They may or may not include the other options, and
they are available for use from any form within the Class of Processes.
A thorough explanation of the Base Document creation and operative can be found in the documentation
on Document Management.
4. EXAMPLE OF MODELING
This example presents a Class of Processes called Purchase Authorization for a construction company. It is
a simple example with few objects, to make it easier to follow. However, the mechanics used are of general
application in other Classes of Processes, whatever their complexity.
For carrying out the MODELING, the first thing to do is create the Class of Processes to be modeled. To do
this, enter the Processes Family in Structure and choose Processes: Tree and Classes.
The Tree and Classes window has the following appearance:
Click on Create (1) and the window from where the Class of Processes is created and modeled will appear.

After entering the IDENTITY data (explained previously in this document) the model is created from the
EXECUTION section. In this example, only the Diagram and the Objects are used, as the Panel and Com-
ment Logs fields are configured from the Personal Tasks.
4.1. Diagram
Click on the Diagram configuration icon to enter the diagramming tool.
There are two versions of the AuraPortal Modeler: AuraPortal BPM Modeler-Visio, which requires prior
installation of Microsoft MS Visio (2003/2007/2010), and AuraPortal Helium Modeler, based on Java,
which requires no third-party programs.
For more information about the use of these tools, refer to the corresponding documentation.
Note.
To check the simplicity with which the Diagrams are created, refer to the
www.auraportal.com website. In the Knowledge-Videos section you will find some
interesting videos about this topic.
Below is an image of the Diagram of the Example Process, once it has been created:

It is important to remember that, when the diagram is saved, the system creates the Objects with the same
name and description provided in the diagram. They are also given a code which, proceeded by the name
of the page of the diagram they are in, will act as a means to identify them in all the operations where they
intervene. For example, the first Task, TP.1, is identified by 1.TP.1, as it is in the first page, and likewise with
the rest of the objects.
Given the educational nature of this example, the Model conceived is simple to understand and at the
same time contains a variety of elements that demonstrate AuraPortal’s extraordinary power. In the Model
of this Example we can find Personal Tasks, Messages, Roles, Subprocesses, Time Events, System Tasks, etc.
Note.
Refer to the Helium Modeler Manual for details about constructing the diagram.
Explanation
This Class of Processes has been conceived as a basic example for managing indirect purchases that are
not controlled by the ERP, such as furniture, office material, computer systems, spare parts, etc.

The process starts when a certain employee fills in a Request Form for goods. By filling in this form a Mes-
sage is generated which is detected by the AuraPortal Motor, which immediately starts a Process of the
Purchase Authorization Class and gives it a Process order number inside that Class.
Once the Process is initiated, a Personal Task named The Supervisor Approves appears in the Supervisor’s
queue of pending Tasks. When they open it, they examine the data coming from the Start Message as
indicated in the Task instructions. When they have made their decision to approve the purchase or not,
they fill in the Form to note this decision. Then the Task is terminated and the flow arrives at the object: 1st
Approval? Gateway.
If the purchase isn’t approved, the Gateway drives the flow to the Informs of NO Approval System Task
and the Process is terminated. This System Task sends an internal message to the Requester, notifying
them that their purchase hasn’t been approved.
If on the contrary the purchase has been approved by the Supervisor, the flow arrives at the Needs 2nd
Approval? Gateway. This Divergent Gateway decides if the purchase already approved by the Supervisor
requires a second approval by the Division Manager. In order to do so, the Gateway must know the pur-
chase cost.
• If a second approval isn’t necessary, the flow passes through a Point of Control K.1 that is re-
sponsible for taking note of the moment the flow passes through it, in order to extract data for
the Tracking.
• Next the flow arrives at the Personal Task which notifies it has been approved and the Purchase
and/or material delivery and/or stock update flow continues.
• If a second approval is needed, the flow reaches the Time Event: Only Monday and Thursday
from 10:00 to 12:00, which freezes the Process until either Monday or Thursday between 10:00
and 12:00. When these conditions are met, the Event allows the flow to go through.
The reason this Time Event has been included in the diagram is that the Division Manager only re-
views approval petitions on Mondays and Thursdays from 10:00 to 12:00. It is not desirable for the
mentioned approval Tasks to appear in the workflow queue before these periods, as they would
remain in queue without being opened by the performer until the specified moment, and the
presence of these Tasks in queue would cause inconsistencies in the Process Tracking implying
that the Division Manager isn’t attending to his workflow diligently, even if not the case. It would
also distort the statistics concerning workloads and optimal resources allocation.
When the time specified in the Time Event is met, the flow passes on to the Personal Task Ap-
proved by Division Manager. In this Task the Division Manager examines the purchase request
record already approved by the Supervisor and decides whether to approve it or not. The process
flow continues its course depending on this decision, as described above.
On the whole, the Diagram expresses the intended actions of the Class of Processes, i.e.:
• Allow the creation of an approval request for the company’s indirect purchases.
• Send this request to 1st Approval.
• Decide if a 2nd Approval is required, depending on the internal Business Rules.
• Adjust the partial execution times of the Process by means of pauses to avoid the generation of
misleading Task queues.

• Ensure that the system automatically sends the Messages to the recipients that indicate if the re-
quest has been approved or not.
• Execute Subprocesses with the Purchase Tasks if the requested goods are not in stock.
• Establish, by means of Points of Control, the Spans that have to be measured in order to detect
bottlenecks and optimize the workload distribution.
• Control the participants through their Roles.
4.2. Objects
The Objects used in the Model are Classes (Classes of Task, Classes of Subprocess, Classes of Events and
Gateways) and their names are the ones appearing in the Diagram. This way for example, the Object with
code TP.2 named Approved by Division Manager is a Task Class and in all Processes of the same Class of
Processes this object will be the same.
For lexical simplicity reasons, when talking about the Diagram or Model Objects, which always corresponds
to the Class of Processes, sometimes the following names are directly used (when there is no case of con-
fusion): Tasks, Subprocesses, Events and Gateways, understanding that it refers to the respective Classes.
To give the various objects of the Diagram their attributes, click on the icon next to Objects in the Class of
Processes window and the following window appears:
Click on the image in the right hand panel to show the Diagram:

As seen in the image, all the Objects drawn in the Diagram that appears on the right side of this window
are found on the left side of the same window, grouped by categories, under their corresponding tabs:
Tasks, Events and Gateways.
Here are also found, the Spans tab for entering the Span definition between Points of Control, as well as
the Base Document for creating templates that will serve for the automatic document creation in the pro-
cesses.
For giving the Objects their attributes, normally the same order used for the Diagram flow is followed. This
way the progressive construction of the Class of Panel easier with the fields as being necessary for the ob-
jects is made easier. It’s the following:
4.2.1. Step 1: 1.IM.1 Start Message

Firstly, the Start Message found amongst the Events (1) is configured.
Clicking on the object (2) will open a window like the following:
Note.
The CALENDAR VIEW panel only appears after saving the form, selecting User =
Employee, given that this feature is not available to External and Guest users.
The Type and Name identifying the event have already been created by the system. The Description shows
the text introduced as such in the diagram object (in the previous image it is blank). If the Text to Docu-
mentation field is filled in, this text will appear in the Class of Processes Documentation (Descriptive and
Detailed Document). This tutorial only shows the steps to follow to carry out this example, assuming that
the operative is already known. If not, the explanation about the concepts and operative of Form creation
can be found in the documentation on Dynamic Forms.
Note.
For designing Forms, a minimum screen resolution of 1280x1024 must be used.
Clicking on the Form configuration icon will open the Create Form window:

As seen in the image, this window contains an Action Bar and four panels:
Actions Bar (1). In the upper part. Contains the buttons that perform the general window actions.
IDENTITY (2). In the upper right part. Determines the form identity.
DIVISIONS (3). In the right central part. Contains the Creation Buttons of the Active Divisions and the Grid
on which all the Form’s active divisions appear with their respective columns, so as to be managed.
SELECTED FIELD LIST – DIVISION – Division Name (4). In the lower part. Contains an Action Bar and the
Field Grid of one Division (the one selected from the Divisions Grid to work with). Here, the Fields, But-
tons, etc. that each one of the Form’s Active Divisions will contain are determined and configured.
Page Canvas (5). In the left central part. It’s the background on which the form is designed.
For creating a form, in general, follow the steps below:
1. Firstly, enter the Identity.
2. Next, create the form’s Active Divisions.
3. For each of these Divisions aggregate and configure their Fields and Buttons from the Division’s
Selected Field List, as well as the Complements and other features.
4. Finally, the form appearance is designed in the Canvas, with all the added elements.
4.2.1.1. Action Bar
In this example only page 1 is used, which comes by default and the rest of the buttons won’t be used.

4.2.1.2. Identity
In this example the identity data are the ones shown below:
The Forms are lodged in Chapters of their Dictionary. Once selecting the Chapter, enter the Name: Initial
Application (IM).
Then, in the User field, select Employee as this IM performer. This indicates that only employees can start
this process, in detriment to External, Guest, or Anonymous Users. This differentiation is necessary as the
fields that can appear in the Form are different depending on the user nature. It is also necessary for as-
signing the Tasks on the Processes, when these depend on the Start Message Author.
Next, by clicking on the More Information icon, the desired behavior options of the IM are marked and the
dimensions and screen position of the General Window that will be used to execute this Form are deter-
mined. Following this example, the values appearing in the next image are entered:
Note.
The access protection to this form execution is achieved by including it in a Secure
Room (see the Secure Rooms documentation for details of this operation).

4.2.1.3. Divisions
To create Divisions, click on the Create Original Division button in the action bar of the Division Grid. A
window with three sections will appear: GENERAL DATA, DESIGN and TEXT IN BASE LANGUAGE. Firstly,
introduce the GENERAL DATA.
Introduce the Name (Main Form), Description (optional) and click the Save button. Several more fields will
appear:

Presence depending on Conditions. To specify whether the Division presence in the Page must be perma-
nent (always appearing when the page appears, as in this case) or conditional (appearing only under cer-
tain conditions). In this example No has been selected.
Excluder. In execution, when a division marked as Excluder = Yes appears, either on opening the form,
because it is triggered or its conditions are met, all other divisions will be hidden. When the Excluder divi-
sion is hidden, all the divisions that were hidden will reappear (as long as they still meet the conditions). In
this example No has been selected.
Access. This option makes the division appear either in Read Only mode or not, depending on the design.
Select Following Design. The division will appear as has been configured in the design.
The appearance of the division is also designed here in the DESIGN panel. In this Example Customize has
been selected, and in the HEADER panel Visible has been set to No. As will be seen further on, we are go-
ing to include a header as a complement. See the image below:
The third panel, TEXT IN BASE LANGUAGE, allows text to be introduced that will appear in the header:

Once the text in Base Language has been introduced, Multi-Language can be configured by clicking on the
corresponding column in the Division Grid. See the image below:
This characteristic is not used in this example.
Two more Divisions will be created in the same way:
• Short Description. This will contain the description of the requested element.
• Data of the Request. This will contain the data of the requested element.
Both Divisions will be created with Presence depending on Conditions = No and the same Design attrib-
utes, but with the Header NOT Visible and with an Image for the body.
With the created Divisions, a List of Divisions is generated, as can be seen below:
Click on the Division Name you wish to design, and the Division Name will appear in the Selected Fields
List panel.
4.2.1.4. Selected Fields List
By clicking on the each of the created Divisions the actions bar of the Selected Fields List in the lower part
of the window will become active. The actions bar contains the buttons shown in the following image:

The buttons, except for Aggregate Fields, all refer to elements that can be included in the form.
Note.
The explanation of these concepts and the operative of these elements can be found
in the Dynamic Forms documentation. This document only covers what must be
done to configure the example, assuming that the way how is already known. If
that is not the case, have the Dynamic Forms documentation at hand.
Now we will look at an explanation of the three Divisions in the example: Main Form, Short Description and
Data of the Request.
4.2.1.4.1. Main Form Division
Following the example, by clicking on the Division Name Main Form, the Action Bar of the List will become
active. To configure this Division, proceed as follows:
Create Complements
The easiest way to add images to a form is with Complements. In this example we are going to add a
header with a logo and a title, as can been seen in the image below:
To create Complements, click on the division where you want to add the image and then click on the Cre-
ate Original Complement button in the action bar of the Selected Fields List:
A window like the one below will appear:

After introducing an Internal Name and Shown Title (1) to identify the complement, select the Image radio-
button (2) in the BODY panel. In this example we select the Private Images tab (3) because the image
we want to include is not in the AuraPortal Images Gallery. If we know the name of the image, in this ex-
ample, Purchase Authorization – Header (4), we write it in the Image Name field. If not, click on the Pro-
ceed button (5) to display all the images. When the desired image is selected (7), click Accept Selection
(8).
Note.
If the image does not exist in the Private Images gallery, click the Add New but-
ton (6) to incorporate it in the gallery.
In this example we haven’t configured anything else in the complement. Click Save and Exit. The image will
appear as seen in the image below:
After expanding it to the desired size, it will have the following appearance, situated as the header of the
form:
Note.
For more information about configuring Complements, consult to the Dynamic
Forms documentation.
Aggregate Fields
By clicking on the Aggregate Fields button the Panel window will open:

Clicking on Proceed will open the list of available fields in the grid. Before clicking Proceed you can filter
the list by Term Type, Data Type and Name (1).
Initially, this window only contains the System fields (which are preceded by “_” and come included in the
Division by default). If more fields are needed, they can be added from the Dictionary of Terms. To access
the dictionary, click on the + Aggregate Fields button (2).
When you have checked the boxes of the desired fields, click the Accept Selection button (3).
Note.
Each Process has its own Panel, which is of vital importance as it receives, lodges
and supplies all the information generated in the Process.
Each time a Process is initiated the Motor creates a Panel specifically for this Process, which is
made from a template unique for all Processes of the same Class.
This template is named Class of Panel and contains the names of the fields that
must be available in each Process Panel in the Class. In turn, these names are ob-
tained from the Dictionary of Terms in the AuraPortal Structure.
The following window will appear:

To make a selection, as the number of terms housed in the Dictionary can be very high, a filter can be
established (1). By clicking on Proceed, the terms that meet the filter will appear in the list (2).
To create terms, click on the buttons in the action bar (3), according to the type of term you wish to cre-
ate.
The operative and concepts of the creation of the different types of Terms are explained in the Delegated
Administrator Manual.
In any case, by selecting the desired fields in the Dictionary and clicking on Accept Selection (4), they will
be inserted in the Panel.
In this example the fields the Start Message needs are the following:
1. Requester Name. A Prefix of the Employees Family.
2. Requester Name /ID Number. A Suffix of the Employees Prefix. Leave the Shown Name as it is.
3. Requester Name /Job Title Telephone. A Suffix of the Employees Prefix. Change the Shown Name
for: Telephone.
4. Requester Name / Job Title Telephone Extension. A Suffix of the Employees Prefix. Change the
Shown Name for: Extension.
5. Requester Signature. A Digital Signature type General Term. The signature is configured by click-
ing on the configuration icon in the C column (size 100%, Signature footer Yes and Signature
Footer Font 7pts).
As already mentioned, the operative and concepts of form creation are explained in the Dynamic Forms
documentation.
Following the Example, to configure the fields the following actions have been performed:
1. The fields Requester Name, Requester Name /DNI, Requester Name /CompanyPhone, Requester
Name /Company Phone Extension and Requester Signature have been aggregated.
2. The Shown Names have changed from the L column, where necessary.
3. The fields have been marked as ‘R’ and ‘E’, which means they function in Edit (E) or just Read (R)
mode. The Employee Prefix is configured to take the value of the Start Message Creator. The suf-
fixes will load automatically with the value they have in the corresponding employee record. The
Prefix and Suffixes are shown as read-only.
4. The Requester Name has been marked as Theme.
Add Buttons
By clicking on Buttons in the action bar of the SELECTED FIELDS LIST, the button configuration window
will appear:

Give the button a Name and a Description (optional) and click Save. All the other fields will then appear.
Note.
The Name chosen here can be changed at a later date to apply Multi-Language. In
this example we will name it Terminate, although later on we will name it Proceed.
For more information, consult the Dynamic Forms documentation.
To add the desired action to the button, click on Aggregate Actions (1) and select the action, in this ex-
ample Terminate (2), and then click on Accept Selection (3).
In this example we are going to customize the button design using an image. See the configuration win-
dow below:
Note.
For more information about button configuration and the available actions, consult
the Dynamic Forms documentation.

Set design as default has been marked as Yes so that any other buttons are created with this design.
In this Example, the buttons the Start Message needs (in addition to Terminate) are the following:
Close. With the Exit action, to be clicked by the performer of the Start Message when wanting to close
this Division (Main Form) in order to exit it.
Print.Reg. With the Automatic Document action, to be clicked by the performer so that AuraPortal
automatically creates the Print Register document.
To configure this button, enter the Name Print.Reg and in the ACTIONS IN FORM section select Save
the form before creating the Automatic Document.
By clicking on the Update Fields button and ordering and distributing the created elements in their correct
place on the Canvas, the Form will look like this:
The form title, Request Form (1), has been added as a Complement because, although the Header will be
the same for other forms, in each task the title will be different.

4.2.1.4.2. Short Description Division
Following the same operative as in the previous Division, add a One Line Text Field named Short Descrip-
tion and a Complement for the image. By placing them on the canvas they look like this:
4.2.1.4.3. Data of the Request Division
Following the same operative, add the Request for (Item) fields: Urgency Level, Status, Observations, At-
tached Documents, Units, Request for /Cost value and Total Amount.
Next, configure them so they appear as shown in the list below:
By clicking on Update Fields and arranging the created fields in the Canvas, the form will look like this:
4.2.1.5. Page Canvas
The Page Canvas is the background where the Active Divisions are placed (with their Fields and But-
tons), as well as the rest of the graphic objects that form the Page, both individual and inlaid in Comple-
ments.
The fields added from the Panel to the Form will automatically appear on the Canvas. If any changes are
made once they have been added, click on the Update Fields button to update the Canvas.

Once all fields are on the Canvas, they must be positioned correctly. The resulting form may look like the
following:
4.2.2. Step 2. Personal Task 1.TP.1 Supervisor’s Approval

The Tasks tab shows the list of the tasks existing in the Diagram.
By clicking on each one of them, a window appears for giving the attributes to this Class of Personal Task.
As in the Classes of Processes, the data to supply for each Object (Tasks, Events and Gateways) are grouped
in three sections shown in their respective boxes: IDENTITY, EXECUTION and CHRONOMETRICS, and,
where appropriate, CALENDAR VIEW.
Remember that the concepts and operative of the Modeling Window are explained in a previous
chapter of this Document.

4.2.2.1. Identity
On entering, the Type ((TP) Personal Task) and the Name (The Supervisor Approves) that identify the
task have already been created by the system. The Description box shows the text introduced as such in
the diagram object (in the example above this box is empty). If the Text to Documentation field is filled in,
the introduced text will appear in the Documentation of the Class of Processes (Descriptive and Detailed
Documents). A different color can also be chosen to appear for this task in the Planning.
Complete information on Planning Management can be found in the Planning documentation.
To give attributes to a Personal Task, firstly determine if it must be performed by an Employee, an Exter-
nal User (who communicates through the External Portals) or a Guest User (who communicates through
the Public Web and/or by Email or other similar mechanisms).
Following the example, in this case the task Supervisor’s Approval is performed by an Employee.
4.2.2.2. Execution

Firstly, the task is configured as Clone Enabled: the task behavior when the flow passes through it more
than once. It doesn’t affect this example.
Participants
Here the users that will intervene in the task in some way are defined: Performer, Responsible, Emergency
and their Substitutes. In this example, the Performer is the Role of the Requester’s Supervisor. In order to
define it, the procedure shown in the images below must be followed.
In this example mark the Supervisor (in Grade 1, the direct supervisor) of the Start Message Creator.
Instructions
The Instructions that will be seen on the Task Performer’s screen can be as detailed as necessary.
In this example, for this Class of Task a Text has been chosen. By clicking the Edit Button, the rich text
editor appears, for entering the text to be seen in the Instructions:

Workplace
Next the following are defined:
1. Predefined Format
Choose here the Task Execution Window Format that the Task Performer will see when performing the
Task. The Formats will have been previously designed from the AuraPortal Structure, in Processes – Envi-
ronment, although they can also be created here.
By clicking on the icon, the list of the already created models appears. Click on one of them to access its
Edit window, to Consult it or Modify it. To create a new model, click on the Create Model button. For this
Class of Task, a Format named TEW 1240 x 725. 80f-60i-40h has been created with the following parame-
ters:

2. Forms
In this example only one form is needed. To create it, select Yes in the Forms option, click on the icon and
a window will appear where you can choose whether to create an Original Form or a Similar to other,
which is already available.
In this case the form will be similar to the Start Message form. Click on the Similar to Other button to
open the Form search window and select the Start Message, which will be integrated in the list of Forms.
By clicking on the form the system creates a copy of it in the Form Creation Window, to be modified. Once
open, a Name must be introduced: Supervisor Approval. 1.TP.1 and then click Save for the elements in the
creation window to appear.
Note.
The Creation Window for the Task Forms is similar to the one explained for the
Start Messages in the previous section. For a more thorough explanation, consult
the Dynamic Forms documentation.
IDENTITY (at the top right)
In this example, to configure the Identity click on the More Information icon and mark the fields as shown
in the following image:
DIVISIONS (in the middle on the right-hand side)

The divisions appearing here are from the form that we have copied, in this case the Start Message Form.
However, they can be modified. In this example, we will not change them, we will only add two new Divi-
sions:
1. Button Panel. To lodge the process action buttons.
2. Approvals. With the fields the performer will use to make a decision.
SELECTED FIELDS LIST (at the bottom of the window)
To configure the form of this task, the Start form divisions will be modified and the two new ones will be
configured from scratch. In any case:
From the ‘Main Form’ division:

• Click on the icon in the list to unlink the Terminate, Close and Print Reg. buttons.
• In the fields shown in the window (which are the ones coming from the Start Message) unmark
the E (edit) box, keeping the R (read) box marked, so that the performer can see the fields but not
modify them.
From the Short Description and Data of the Applied Element divisions:
Unmark the E (edit) box from all the fields, keeping the R (read) box marked.
In the Button Panel division:

Aggregate three buttons, the same way as explained before, as seen in the image below:
The Approve button is a Trigger, which means that when the task performer clicks it, the Approvals win-
dow (division) appears. This means that in the configuration window, apart from the other elements, the
trigger must be configured as well by clicking on the Create Actions button.
In the Approvals division:

Aggregate three fields (Supervisor Approves?, Supervisor Signature and Reasons for rejection) and the
Close button for closing the Division. The Division will look like this:

3. Comment Logs
The Comment Logs of a Process contain who has taken part in each task, when they did so, as well as all
comments added by the successive participants. Each Class of Processes can contain as many Comment
Logs as needed each acting in different tasks. This way, the information they contain will only be available
to the relevant users. So, for each Task, the access to the relevant Comment Logs is defined from this field.
Comment Logs can also be created from the corresponding option in the Workplace panel of the TP con-
figuration window (1). See the following image:
Click on the Aggregate Comment Logs button (2) to add existing Comment Logs or create new ones. In
this example, we have created a Main Comment Log especially for the approvers and a Secondary
Comment Log for everyone else (3).
CHRONOMETRICS
In this example, we have defined the parameters that appear in the window on the Process Calendar and
entered the following values:

This way, besides the Expected, Minimum and Maximum Duration control, when two working hours are
remaining (Alert Threshold) until the Maximum Duration is reached, an Alert will be produced which will
generate a warning to the user indicated in the Notifying Message to option. In this example it’s the Re-
sponsible of the Class of Processes (this last data is not shown in the window because there could be more
than one warning recipient, but this can be consulted by clicking on the search icon).
4.2.2.4. Calendar View
The Calendar View has already been explained in another part of this document and in detail in the specific
Calendar View document. It is not applied in this example.
4.2.3. Step 3. 1.DX.1 1st Approval?

In order to give the Gateways their attributes, click on the Gateways tab and the list of all the Gateways in
the Diagram will appear:
The 1.DX.1 Gateway window is as follows:

BEHAVIOR
Default Outlet (1). In the particular case of the DX Gateways there must always be a Default Outlet (that
always allows the flow to go through when the rest of the outlets don’t comply with the conditions), to
make sure that the flow won’t stay blocked in the Gateway. In this example, the one named Approved (as
the Diagram connection line that corresponds to this outlet) is defined as Default Outlet.
Outlet Name (2). It is automatically supplied by the system. Since the Gateway has only two outlets, the
only conditions to be defined are the ones that determine the not Default Outlet, that is, the Not Ap-
proved.
Description (3). An optional field for extending the description of the Outlet which helps to identify the
conditions established without having to enter the configuration page of each one.
Order of Evaluation (4). In Gateways with more than two outlets the order in which the Motor must evalu-
ate each Outlet conditions also has to be indicated. This way, when one Outlet complies with the condi-
tions the rest are not evaluated, so in cases where the Outlet preferences differ, the descending evaluation
order is very important. When just one Outlet must be evaluated, as in this case, there’s no reason for spec-
ifying the order.
Conditions (5). Click on this icon and the following window appears:

Using the Create Conditions button the conditions are created and they appear in the lower list to be con-
sulted. If creating more than one condition, the Logic Operator to be applied must be selected: AND (if all
must be met), OR (some) or XOR (only one).
By clicking on the Create Conditions button a new window will open. The Gateway Name and Outlet Name
are supplied by the system. The Condition Name is an optional field for giving the Condition a name.

REAL DATA
Source. In this field, choose Panel.
Field. Here we indicate the Panel field whose value will be used for the Condition evaluation. To do this,
click on the search icon to open the Class of Processes Panel where we can choose the field. In this exam-
ple, the chosen field is Supervisor Approves?, where the 1.TP.1 Supervisor’s Approval Task Performer
will have uploaded the corresponding Yes or No value in the Task Form.
Data Type. Once the field has been indicated, the system shows the Data Type corresponding to this field,
according to the Dictionary of Terms. In this case Yes/No.
Now the window is enlarged to indicate the COMPARISON value that allows the Condition compliance to
be defined. In this case, the following options will appear:
COMPARISON
Operator. Here we can choose between: Equal and Different from. In this example Equal.
PATTERN
Source. We have chosen Fixed.
Value. The only options are Yes and No. Choose Yes.
Click on Save and Exit to return to the conditions window:
The Logic Operator intervenes only when the same Gateway has various Conditions. In this case there is
only one Condition, so it doesn’t intervene.
Click on Save and Exit to return to the main window.
CHRONOMETRICS
Calendar. Here the same Calendar generally defined for the Class of Processes can be selected or one
particular for this Gateway.

Gateway Clock. Here we can choose between the Process Clock (implies that the same Clock generally
used for the process will be used) or directly the server or a local Clock.
In this example the Outlet named Approved is validated by the Motor and the flow reaches the DX.2
Gateway.
4.2.4. Step 4. 1.DX.2 2nd Approval?

This Gateway is responsible for analyzing whether a second approval is required or not. Let’s assume the
result is Yes (and therefore a second approval is necessary) when the investment amount is more than
300€. If the investment amount is less than 300€ it leads to the No outlet and therefore the approval of the
Division Manager isn’t required.
To configure it, follow the same steps as in the previous one. In this case:
− Firstly, set the No outlet as the Default one (no approval is required).
− Then, define the Yes Outlet Condition, this being that the Total Amount field is Greater than or
Equal to 300€.
CHRONOMETRICS
The data to supply are: the Process Calendar and the Gateway Clock to be used by the Process. In this ex-
ample the Yes Outlet will be validated by the Motor and the flow will reach Event ET.1.
4.2.5. Step 5. 1.ET.1 Only Monday & Thursday from 10:00 - 12:00
The aim of this Class of Time Event is to prevent the Process flow from continuing when it arrives, until
either Monday or Thursday and between 10:00 and 12:00.
IDENTITY
Next the Identity box is show, already filled in:

Introduce the following Description in the Rich Multiple Line Text field (1):
Detain the process current until Monday or Thursday, and only let it through between 10:00 and 12:00 on
these days.
CHRONOMETRICS
Calendar. In this Example choose the Process Calendar.
Event Clock. Choose the Process Clock.
Options
The ET conditions are established by clicking on the Control by Date configuration icon (2).
Although various options are permitted (which means that diverse time controls can be given and the sys-
tem will class the first to be complied as valid), in this Example just one option will be taken into considera-
tion, based on a Control by Date (not Control by Duration, as it’s not about controlling a measured delay
but certain dates: Mondays and Thursdays).
To configure the option, after marking Control by Date click on the configuration icon and in the window
that appears and indicate the following parameters:

Choose Modality, which in this Event is Only Weekdays. By clicking on the configuration icon, the following
window will open to choose the desired weekdays:
Notice that only the Weekdays Monday and Thursday have been marked. If no Week of the Year is indicat-
ed the system understands that all weeks are valid. However, as the chosen Calendar already contains the
workdays and holidays, if Monday or Thursday are holidays the Event won’t be activated.
Now, to define the 10:00 to 12:00 interval click on the Control by Hours configuration icon and the follow-
ing window will open:

In this window it’s been indicated that the Validity Margin is 120 minutes (2 hours), which means that the
current will be allowed to pass through at any moment inside this margin, starting from the hour indicated
in the lower box, in this case 10:00.
Once the flow has passed through the Event 1.ET.1, it reaches the Task 1.TP.2.
4.2.6. Step 6. 1.TP.2 Approved by Division Manager

This Class of Personal Task is very similar to the 1.TP.1 Supervisor’s Approval shown before, so it’s not
necessary to repeat the detailed explanations given there.
The main differences from the Class of Task 1.TP.1 are:
• As Performer, mark Role: Singular and select Division Manager.
• No Instructions are used.
• In the Form, the Approvals Division looks like this:
When the Performer finishes this Task, the flow passes to the Gateway 1.DX.3.

4.2.7. Step 7. 1.DX.3 2nd Approval?
This Gateway is practically the same as the 1.DX.1 1st Approval?, explained previously. The only difference
is that the Panel field the Gateway observes in order to see its value is called Division Manager Approves?
instead of Supervisor Approves?.
In this example, the valid Outlet of this Gateway is the one called Approved and then the flow reaches the
Point of Control K.1.
4.2.8. Step 8. Points of Control 1.K.1 and 1.K.2

To give the Points of Control and Spans their attributes, click on the Spans tab and the list of the Points
that appear in the Diagram will appear:
The Points and Spans are not taken into consideration in this example.
After this Point of Control K.1, the flow reaches the Personal Task TP.3.
4.2.9. Step 9. 1.TP.3 Notifies of Approval

This Class of Personal Task acts in a similar way to the others (TP.1 and TP.2) explained previously, so it’s
not necessary to repeat the explanations that were given there. In this case, as the aim is to notify the re-
quester of the approval of the purchase:
1. As Performer mark the Start Message Creator.
2. No Instructions are used.
3. The Form is a Similar Creation of the previous one, with the following differences:
• In all fields, the Edit boxes must be unmarked, so that the performer won’t be able to modify the
values.
• The Approvals Division is eliminated.

• In the Data of the requested element Division the following fields are added:
o Stock Available. It is the Suffix Request for/Cost Value.
Note.
This field from the Items Record has been used in this case to register the available
stock quantity, to simplify the example.
In a real case this field would come from either the Warehouse Management of the
ERP the company works with or, failing that, from an Items Annex created for stock
control.
o Calculated Stock. It is a Decimal Number General field, configured as Calculated to subtract

the Requested Units from the Available Stock ([0_2_Request for/Cost Value] - [0_3_Units]).
It is shown below:
Then two new Divisions are created:
1. Location. With the Suffixes Request for/Comments and Request for/Responsible.
2. Warning 01. Designed in the following way:

4.2.10. Step 10. 1.DX.4 Material Available?
This Gateway acts in a similar way to the previous ones. In this example, the Yes Outlet will be validated by
the Motor and the flow will reach the System Task TS.2.
4.2.11. Step 11. 1.TS.2 Notifies of Delivery

This Class of System Task sends the requester a Notification, informing that there is material available and
therefore they can proceed with collecting the requested material.

In the example, to give attributes to this task:
Function. Choose NOTIFIER – (Notifies Employee Users).
Addressees. Mark General and select the Start Message Creator.
Content - Text. Introduce a text informing that there is material available and the user can proceed
with the material collection.
Sender. Mark System.
Documents. Mark Yes and select the Attached Documents field.
Once the flow passes from this TS it reaches the Task TP.4 Collection of Material.
4.2.12. Step 12. 1.TP.4 Collection of Material

This Class of Personal Task acts in a similar way to the previous ones handled before and so it isn’t neces-
sary to repeat the explanations given there.
In this case:
1. As Performer, select Panel, then General and choose the Item Suffix Request for/Responsible.
2. No Instructions are used.
3. The contained Form is a Similar Creation of the previous one, with the following differences:
• In all fields unmark the Edit boxes, so that the performer will not be able to modify their val-
ues.
• Delete the Location division.
• Modify the Warning 01 division content, so that it looks like this:
4.2.13. Step 13. 1.TS.3 Updates Stock

This Class of System Task automatically updates the moved stock after removing the requested material.

In this example, to give attributes to this task:
1. Function. Choose UPLOADER – (Uploads Information or Calculated Value to Panel).
2. Direct Upload. As shown in the image:
Once the flow has passed through this TS, it reaches the End Event (FN), which terminates the process.
Modeling Terminated

AuraPortal has constructed the programming code for the Motor that will direct the process execution. No
programming is required, even for carrying out the most complex processes. This characteristic clearly
differentiates AuraPortal and offers an important product appeal.
5. EXAMPLE OF EXECUTION
Each Process EXECUTION is carried out by the Process Motors (there can be various motors working to-
gether in the same process, because each flow thread is controlled by a motor). The Orchestrator starts
the Motor when a Start Event (by Message, Time or Register) is triggered.
As already said before, once the Model is finished and the appropriate Simulations have been carried out
in order to confirm that the Process is working properly (all this is carried out by the company executives or
by business consultants without any programming needed), all that’s left is to put the Class of Processes
into Production Mode and, as a result, processes of this Class will be automatically initiated when the Start
Event is triggered.
In this Example, once carrying out the Class of Processes Modeling as explained in the previous chapter,
the Process passes to execution, without any type of programming.
Note.
It is also possible to put a Class of Processes in Development Environment into Pro-
duction mode, configuring it so that Processes can be started. This has the ad-
vantage of greater flexibility when making adjustments or modifications, but it re-
quires great care to ensure that the changes do not affect the processes already in
execution.
5.1. Process Initiation

This Example manages the Purchase Authorization Class of Processes, which initiates its Processes by
means of the 1.IM.1 Initial Request Message Event.
The Ap4 user (employee) clicks the Start Process button, from their My Tasks window for example. A list
will open with the Start and Intermediate Message Forms they have access to. By clicking on the name
Initial Request the following form will appear:

As can be seen and according to how the form has been designed, the system recognizes and automatical-
ly introduces the requester’s name, and also fills in the ID Number, Telephone and Extension fields, which
appear in his record.
The requester must enter a Short Description of the request (I request for two laptops for my department,
as agreed previously) and indicate the desired elements (Laptop Computer, Brand XXX/features YYY). To do
this, they choose them from the Request for search icon. Then they choose the Urgency Level (High) and
Status of the request. They can also add some Observations (We need them this week) and/or attach any
Documents that may be of interest. Next, they enter the number of Units required (2). The system enters
the Cost/Unit of the element that appears in its Record, as well as the Total Amount of the request.
Next, Ap4 clicks on the Requester Signature icon and enters their digital signature PIN (1234) in order to
sign the form.
Finally, by clicking on the Print.Reg. button a window opens for creating a Print Register document, for
the administrative control of the operation. By clicking on Save in the window the document is automati-
cally created by the system and introduced in the Attached Documents field, according to the configuration
made in the previous chapter. Next, they click on the Attached Documents icon and sign. The document
will be created and signed, as seen in the following image:

After filling in all the fields Ap4 clicks the Terminate button, which starts the BPMS Motor (they could also
click the Close button, if they wanted to save it in draft mode for later on).
The Base Reference of the initiated Process is C1-1.1_1 , indicating that it refers to a Process that is the 1st
instance inside the Class of Processes C1-1.1 (the first 1 refers to the Class of Processes ID and the second
to the version number). This Reference is automatically constructed by the system.
5.2. Process Performance

The first Object that is activated is the Task 1.TP.1, shown next.
5.2.1. Task 1.TP 1st Supervisors Approval

The Supervisor of the requester (Ap4) will see a warning message on their screen generated by the Au-
raPortal Warning Bell, indicating that they have a pending task to open.

By clicking on the link, the Supervisor will see a list of their pending tasks.
Clicking on the line of the new task will open the form just as it has been configured:
Instructions
In this box the Performer will find the instructions he has to follow. If the box is not big enough for all the
text to be seen, he can use the scroll bar or click on the Enlarge button which opens a bigger window.
Forms
On entering the Task, the Form shows the informative data introduced by the requester. Following the
Instructions, after having studied the matter, the performer clicks the Approve button and the following
window opens:
If in the Supervisor Approves? field the Performer selects No, the Reasons for Rejection field will auto-
matically appear (as it’s Conditional it appears only when marking No).
In this example, by marking Yes, the Reasons for Rejection field won’t appear, as it is only useful for justi-
fying the decision if the purchase is rejected. So the only thing to do is sign the form (PIN = 1234). Also, by
clicking on the Attached Documents icon the performer can sign the Administration Control document.

Comment Log
To add comments to the Comment Log click the Edit button. A window will appear for introducing text:
After writing the comment text, click Save and Exit to return to the task form.
Click on the Terminate button to finish the Task. The flow then reaches the next object in the Diagram: The
Gateway 1.DX.1 1st Approval?.
5.2.2. Gateway 1.DX.1 1st Approval?

On reaching this Gateway, the Motor analyzes the Conditions and finds the Yes answer registered in the
1st Approval? Panel field. It then activates the connection with the Approved Outlet, which drives the flow
to the Gateway 1.DX.2.
5.2.3. Gateway 1.DX.2 2nd Approval?

This Gateway is responsible for analyzing whether a second approval is required or not. Let’s assume that
the Result is Yes (and therefore a second approval is needed) when the cost of the purchase is higher than
a certain amount, in this case 300€.
Since in this field the investment is 1,400€, the Motor activates the Yes Outlet (this means that a 2nd Ap-
proval is needed). The flow passes to the Time Event 1.ET.1.
5.2.4. Time Event 1.ET.1 Only Monday & Thursday from 10:00 - 12:00
The flow is detained until Monday or Thursday come around and the time is between 10:00 and 12:00.
As in this Example the previous Task (1.TP.1) was terminated on Thursday at 11:55, the flow has immedi-
ately reached the 1.ET.1 Event (after evaluating and passing through the Gateways 1.DX.1 and 1.DX.2,
which takes practically no time at all).
The Motor checks that the arrival time is within the permitted interval and allows the flow to pass, this way
reaching the Task 1.TP.2.
Note.
As in practice it’s probable that the moment of executing this process is not within

this period, we can access the Class of Processes configuration window (from Struc-
ture), change to Development mode, then access the time event to modify it so that
it enters within this interval. Then, the work can continue.
5.2.5. Personal Task 1.TP.2 Approved by Division Manager

The Performer of this Task is the one assigned to the Division Manager Role (user Ap2), who accesses his
Pending Tasks window and by clicking on the task, the window that opens is practically the same as the
supervisor’s one, and like him, he has to study the request. The window that opens is slightly different:
We can see that the user Ap2 (Division Manager), after reading the Task and examining the attached doc-
uments and comments added by the Supervisor, has decided to approve the purchase. To do that they
mark Yes in the Division Manager Approves? field and then signs the form. Also, by clicking on the At-
tached Documents icon (which isn’t visible in the image because it is below the Approval Form division)
they can sign the Administration Control document.

He could also have added comments to the Comment Log but he didn’t consider it necessary. By pressing
Close in the Approval Form and Terminate in the Main Form, the flow passes to the Gateway 1.DX.3.
5.2.6. Gateway 1.DX.3 2nd Approval?

On reaching this gateway the Motor examines the Approved connection condition, which consists in con-
firming that the Division Manager Approves? Panel field is valued Yes. In this case, the condition is met and
the flow passes to the Point of Control 1.K.1 Point of Control.
5.2.7. Point of Control 1.K.1

The Motor only takes note of the exact moment the flow passes through this point. Then the flow reaches
the next Object: 1.TP.3 Notifies of Approval.
5.2.8. Personal Task 1.TP.3 Notifies of Approval

This Performer of this Task is the Purchase Requester. By accessing the Pending Tasks window and clicking
on this task, the following window will open:
By clicking on Close in the Informative Note, the performer will see that the form contains the Requester,
Supervisor and Division Manager’s digital signatures. In the image above, we can see the 3 Digital Signa-
ture fields behind the Informative Note.
By clicking on the Terminate button, the flow continues to the 1.DX.4 Gateway.
5.2.9. Gateway 1.DX.4 Material Available?

On reaching this gateway the Motor examines the available stock condition which consists in confirming
that in the Item prefix: Request for/Cost Value, which as mentioned in the Modeling chapter is used for
Stock control, is less than 1. In this case, the condition is not met and the flow continues through the Yes
outlet reaching the 1.TS.2 Notifies of Delivery System Task.

5.2.10. System Task 1.TS.2 Notifies of Delivery
This Task, created by the system itself, reaches the requester by sending them a notification to let them
know that they can proceed with collecting the requested elements.
5.2.11. Point of Control 1.K.2

The Motor only takes note of the exact moment the flow passes through this point. Then the flow reaches
the next Object: 1.TP.4 Collection of Material.
5.2.12. Personal Task 1.TP.4 Collection of Material

This Task reaches the performer assigned as the element Responsible (laptop computer), which is user
AP5.
After reading the warning message which contains the instructions to follow, they click Close in order to
access the Main Form.

Once inside the Main Form, the performer marks the boxes corresponding to the material collection and
then clicks Terminate.
The flow reaches the next Object: 1.TS.3 Updates Stock, which automatically carries out this action.
After passing through this TS, the flow reaches the End Event.
Now the Process reaches its End and is therefore terminated.
Note.
If the purchase had not been Approved, or if there was no Available Material, the
flow would had followed different directions and reached other objects.
These are not presented in this tutorial. It is not considered necessary as the behav-
ior of at least one of each object has been shown.
6. EXAMPLE OF MONITORING
The MONITORING allows two things: On the one hand, the possibility to know what is really going on in
every moment and in every living Process during the business activity, with information about time meas-
urements and costs and with the option to intervene in order to correct diversions; and on the other hand,
the possibility to analyze in every detail what has happened in the past in already terminated Processes, in
order to optimize business performance.
The type of data obtained are normally called Key Performance Indicators (KPI). The Indicators chosen
depends on the industry characteristics and the specific needs of each user.
Monitoring is carried out on three simultaneous fronts, the first one through Automatic Procedures and the
other two using Queries:
1. System Controls. While the Processes are running, any Task that reaches the Alert or Alarm threshold,
or any error or other cause that produces a ‘blockage’ in a Process Object, makes the system generate a
warning Notification to the Process Responsible to inform them so that they can act accordingly.

Besides the Notification, the system also blocks the Process if it considers it necessary, until the
blockage problem is solved. These procedures are not created by the user, they come included in
the application.
2. Dashboard. This consists of a series of reports designed for controlling the progress of the Processes,
their current status, the path they have taken, data accumulated, if they are meeting the forecast times, etc.
It offers the following reports:
• Executions
• Views
• Chronometrics
• Task Planning
• Points of Control
3. Business Intelligence. This includes reports for analyzing the process information globally, for making
business decisions.
It offers the following reports:
• BPMS Motor Activity
• Libraries in Dictionary
• External Queries
• Statistics
• Process Status
• SQL Reports
For example, in the image shown below we can see an “In Execution” report of a process from the Purchase
Authorization Class of Processes, which has been used for the examples in this document.

This is an Execution type query in which we can see the objects that have been executed in the left hand
panel (1). They can be seen either according to the design of the Diagram or according to the
Chronology. The right hand panel (2) shows the image of the Diagram, highlighting in red the object
where the current is stopped (3) and the path (4) that the current has followed according to the
evaluation of the gateway outlets.
4. AP Interactive BI. This is part of the Deep BI Module. It is a user-friendly Business Intelligence tool for
AuraPortal business users who don’t have a technical background. This module allows a wide range of
reports to be created using all kinds of charts and allows users to interact with the AuraPortal database to
modify and update values in the family records. Detailed information can be found about this tool in the
document titled Monitoring-Volume2-DeepBI.
5. Excel Reports. This is part of the Deep BI Module. These reports retrieve information about the execution
of BPM processes and export it Excel files to be subsequently analyzed using the full power of the Mi-
crosoft tool. Detailed information about this tool can be found in the document titled Monitoring-
Volume2-DeepBI.
The following tables offer a summary of the types of queries that can be used in AuraPortal with their ap-
plication according to the type of information you wish to query.

DASHBOARD QUERIES APPLICATION
This query allows a thorough control of the execution of each

process, showing:
1. The tracking of the diagram objects that have already

been executed and all their details, including the path
Executions 2. The Chronometrics of the process with the Start and End
Date, Duration, Expiry, etc.
3. All the values of all the Panel fields, including the integrat-
ed Documents and Comment Logs.
4. From this query, it is possible to Stop the process and later

Restart it.
This one shows, in Planning format, the Tasks and Lines of

Task Planning Groups of Fields associated to Dates and Times and assigned to
Employees.
This shows the path of the current through strategically located

Points of Control in the Diagram to analyze the progress of the
processes and detect “bottlenecks”, status, stage and other
eventualities.
Points of Control
The information is shown in Column, Circle, Pie or Pyramid
graphs.
When clicking on one of the values in the graph, all the process
information is accessed.
This query is dedicated to the Chronometrics of the processes

and shows data such as Alerts, Alarms, Critical Level, Status
Chronometrics and Duration, in a grid.
It shows both the Chronometrics of Tasks and of complete Pro-

cesses.
This query allows the joint analysis of process data from a spe-
cific Class. The result is shown in a grid with a line for each pro-
cess, and the data that will be shown can be defined in filters
Views and columns (maximum 12 filters and 12 columns).
Clicking on each process in the grid will open a form with all the
data of the process you wish to show.

BUSINESS INTELLIGENCE
APPLICATION
QUERIES
A query oriented at analyzing the activity of the BPMS Motor,

showing in graph format data such as:
• No. of Active / Started / Terminated Processes

BPMS Motor Activity • Evaluated Objects
• Evaluated System Tasks
• Active / Created / Processed Tasks
• Processed, Active / Created Message / Time Events
This allows viewing the documents in one or several Libraries in

Dictionary at the same time, with their Labels (metadata), re-
gardless of whether they have been uploaded from a Process, a
Role Record or an Own Family, or directly from the Library itself.
Libraries in Dictionary The most relevant characteristics of this query, which differenti-
ate it from the direct access to a Library, are:
1. As it is a Query, the read-only access.
2. That it can show documents from several Libraries at a

time.
In comparison to how the SQL Report queries are oriented spe-
External Queries cifically at MS Reporting Services, with External Queries any

type of report made with any available tool can be executed
through its URL.
The most important feature in the Statistics Queries is that they

allow the analysis of information introduced in Groups of Fields
(and Structured Containers) from different Classes of Processes
at the same time. That is, if the same Group of Fields is being
used from different Classes of Processes, with the Statistics Que-
ries we can analyze all the data as a whole, at the same time.
Statistics Additionally, it is also possible to use this Query to analyze Gen-

eral fields from the Process Panel, i.e., without Groups of Fields.
Although in this case the Query is limited to just one Class of
Processes, it has two interesting characteristics:
1. It allows defining the number of columns with the nec-

essary Panel fields, with no limit.
2. It allows defining the Conditions that must be met for

the data to be shown.
A very complete query that graphically shows the status of the

processes from multiples.
Process Status
It is composed of 60 reports where the Classes of Processes,
their Processes, the BPM Objects (Tasks and Messages), their
Performers, Times, etc., are analyzed from different viewpoints.
This allows the use of all types of reports made with MS Report-
ing Services thanks to the integration of AuraPortal with this
tool, included for free in MS SQL Server.
With this type of query, all kinds of customized reports can be

made, regardless of their complexity, to show statistics, charts,
bottlenecks, KPIs, dashboard, etc.
SQL Reports
The advantages of this type of Query compared with the Exter-
nal ones are:
1. The special integration with MS Reporting Services adds

extra features such as the transfer of parameters and
authentication.
2. MS Reporting Services is a very powerful tool but is in-

cluded in MS SQL Server free of charge.
All the information related to the configuration and execution of Queries is included in a separate docu-
ment about Monitoring-Information Analysis and KPI.
APPENDIX A1 - AURAPORTAL AND PROCESS STRUCTURE

A Model creation for a Class of Processes requires the presence and use of support platforms that are of
general use in AuraPortal. Therefore, they’re not of exclusive BPM module use, even less each Class of Pro-
cesses use, but they are an indispensable support for the Processes function. The AuraPortal Structure
components used in the process Modeling are:
1. Calendars
2. Roles
3. Dictionary of Terms
4. Web Services
5. Adaptors
6. Messages
7. Families

A1.1. Calendars
In AuraPortal there can be unlimited Calendars defined. Each Calendar, which may contain as many years
as desired, is identified by a name and a description and serves for establishing the holidays, as well as the
working hours of all the days included in it. Calendars are mainly applied to Classes of Processes, although
they can also be applied to the objects if required.
The creation, query and edition of Calendars are carried out from the option: Calendars – Create and Edit
in the AuraPortal Structure window. See the image below:
They are explained in detail in the Delegated Administrator Manual.
A1.2. Roles
Role is the name of the function or responsibility held by one or more users within the AuraPortal system
with a view to their intervention in the Processes. They are sometimes necessary for defining the partici-
pants in the Personal Process Tasks. There are three types of Roles: Singular, Generic and Impersonal
Account Role Names.
1. A Singular Role is the one who’s Assignee (user or group that owns the Role) is defined as a fixed
character, meaning that once the Role name is identified, the Assignee is known regardless of the
context it acts in. The Assignee depends only on the Role name.
Some examples of Singular Roles are: ‘Quality Manager’, ‘Warehouse Responsible’, etc., who’re al-
ways the same Employee or Group regardless of the context they act in.
This eases the maintenance of the Classes of Processes if, for example, the Quality Manager
changes, given that the assigned task reaches the Role, regardless of the person assigned to it.
2. In a Generic Role the Assignee isn’t fixed but depends on the place it acts in, called Role Perfor-
mance Place or simply PP. The same Generic Role name can have different Assignees if the Role
can perform in various PPs.

Some examples of Generic Roles are: ‘Department Manager’ (the assignee depends on the de-
partment), ‘Account Responsible’ (the assignee depends on the account), or ‘Site Supervisor’ (the
assignee depends on the Site in question). In these examples, the PPs are respectively the De-
partment, the Account and the Site where the Process is found at that moment.
3. In an Impersonal Account Role Name the Assignee isn’t an employee (as in the previous cases), but
a contact (Personal Role) from a specific Account (External or Guest User).
Due to their importance, the basic concepts and operatives of the Roles are explained in the documenta-
tion about Roles, Profiles and Employees Groups.
A1.3. Dictionary of Terms

The Dictionary of Terms contains the Terms created by the AuraPortal user (the designer of the Class of
Processes for example) and used in Processes to define Process Forms (and other Forms) to define Form
Fields, Business Rules Criteria and Adaptors (connection mechanisms between AuraPortal and other
applications such as ERP, etc.).
Afterwards, the Class of Panel of each Class of Processes (which contains all the fields that are to be used
when performing the Processes of this Class) is configured with the Terms from this Dictionary.
The Dictionary of Terms is accessed from the GENERAL section of the AuraPortal Structure. See the im-
age below:
It is explained in detail in the Delegated Administrator Manual.
A1.4. Web Services

Most of the information stored in AuraPortal is available by means of Web Services, both for entering and
for extracting information.

Many programs can connect to Web Services, both standard applications (MS Access, MS Excel), and pro-
grams designed on purpose with any programming system, such as Java, Visual Basic, Delphi, Visual Stu-
dio.NET, etc.
In AuraPortal there are three different types of Web Services:
1. Generic Web Services, supplied by default by SharePoint (platform on which a great part of Au-
raPortal is developed) and available for reading or writing most of the AuraPortal information.
2. AuraPortal System Web Services, designed for certain purposes and available in default installa-
tion. With them the user can carry out most of the actions he may need from the AuraPortal inter-
face. They’re the following:
• AuraPortalProcesos: Web Service for managing data of AuraPortal Processes. It’s used
for obtaining all the Processes data, Starting Processes, Uploading Documents, etc. (See
Custom Web Services).
• AuraPortalTareas: Web Service for managing AuraPortal Open Tasks, like for example,
Read, Create, Send Modify, Terminate and Delete Tasks.
• AuraPortalDoc: Web Service for managing documents and Annexes is AuraPortal, like
for example, upload, link and read documents in Libraries, Records and Annexes of
whichever any element of all the AuraPortal Families. This Web Service for example is the
one used by the AuraPortal Uploader, a program included in the AuraPortal Utilities,
which makes uploading documents and emails in AuraPortal from Window, Word, Excel
and Outlook a lot easier.
• AuraPortalFamilias: Web Service for managing elements of the rest of the AuraPortal
families (Employees, Accounts, Projects, Items and Areas). It’s used for Creating, reading,
Modifying or Deleting any element.
• AccionBell: Web Service used by the Warning Bell program.
• AuraPortalDiccionarioTerminos: Focused on the handling of Simple Selection Fields. It

enables the terms and their options to be Viewed, new options to be Created, existing
options to be Modified or Deleted and whole terms to be Deleted.
3. AuraPortal Custom Web Services: Both Process Start Message and Intermediate Message
Event forms, which are designed on demand in the AuraPortal Processes, can be published as
Web Services in order to be uploaded from other AuraPortal processes or external programs.
For more information about Web Services, consult the Web Services documentation.
A1.5. Connectors
AuraPortal has a wide variety of mechanisms that allows integrating or connecting with external data to
ease the company’s centralized management as much as possible. Among these mechanisms are the Con-
nectors.
There are several connectors developed by AuraPortal:
• Email Connector. This allows initiating Processes from the reception of an email.
• Excel Connector. This extracts rows from an Excel sheet and converts them into Lines in a Group
of Fields.

• SAP Connector. This allows an easy connection with SAP with no need to program a single line of
code, allowing the integration of ERP data in AuraPortal to be used and modified, including them
in the entity’s Processes. It will be available in the near future.
• Adapters. Included in AuraPortal Adapters Server, they are a set of Connectors, each related to
an external database and developing a specific action. This mechanism allows data to be obtained
for Reading and/or Modifying data in external databases.
The Connectors are configured from the option Connectors – Configure in the AuraPortal Structure. See
the image below:
They are explained in detail in the Integration series, Volumes 1 and 2, of the AuraPortal documentation.
A1.6. Forms
The Form design in AuraPortal is of great importance because the Forms are the most used working ele-
ments during the execution of the Processes. In fact, both the Messages and the Tasks in the Processes
are executed fundamentally via the completion of their corresponding Forms, which means that a good
perception and design of the content and presentation of the forms is extremely important for easing their
use and increasing their effectiveness.
But also, the AuraPortal BPMS provides customers, suppliers and other external users with a Form they can
fill in to communicate with the entity. This is a great opportunity for the Forms to contain, in addition to
the fields that require data, spaces that include commercial and advertising information, such as offers,
adverts, news items, demo videos, etc., which may be of interest to the Customer or Supplier in question.
This valuable platform of commercial action aimed at Customers is enhanced by the fact that the Tasks
within the Processes can be automatically sent to just the Customers of a certain Profile, that is, only to
those that meet certain conditions; for example, those that specialize in a certain product range. The con-
sequence is a specialization of commercial impact especially targeted to select populations of customers.
And all this is possible within the Form itself, which must be filled it with the consequent need for attention,
and not as generally occurs with independent mailing of publicity, which is very rarely read.

Therefore, the possibility of designing Forms with simplicity, but with very valuable content, both in the
functioning and in the appearance, becomes a very powerful goal.
Forms are used widely in AuraPortal and are explained in full in the Dynamic Forms documentation in the
Modeling series.
A1.7. Families
The whole AuraPortal structure resides in the interlaced coexistence of families of elements, which are
shown in the following table:
Employees Accounts
Rules Items
Processes Projects
Open Tasks Areas
Documents Own Families
Note.
The Own Families, unlike the rest of the families (System Families), are created
and designed in AuraPortal according to the particular needs of each organization.
Thus, they belong to each installation (hence the name Own). As many can be cre-
ated as necessary, there is no limit.
In general, it is preferable to use Own Families, both for their current features and for their future projec-
tion. However, at this moment there are three exceptions to this generic conclusion:
• Accounts. This System Family has very specific features that are not available in the Own Families,
such as:
o Account Roles. Through these Roles the human personnel of the Accounts can receive
and manage Process Tasks and Messages.
o External Portals. All the management of External Portals is based on Classes of Accounts
and their Roles.
Note.
In future versions it is forecast that the Accounts will include all the functionality of
the Own Families (Dynamic Forms, configurable Grids, SQL Database, etc.), con-
verting their current functionality.
• Employees. The Employees Family has exclusive mechanisms that are not available in the Own
Families, such as:
o Login. Each employee connects to AuraPortal with a Login, which gives them access to
their specific options and features, not others.
o Company organization chart. A representation of the hierarchical structure of the compa-

ny with application in Processes, Open Tasks and other elements.
o Groups of Employees and Roles. Different levels of organization of the employee with
important functions in the Process workflow, Secure Rooms and permissions.

• Annexes. The Own Families don’t have the Annex concept that the System Families have, but in-
stead the Dynamic Forms features can be used, specifically:
o Fields and Divisions. Fields can be aggregated based on all types of Dictionary Terms,
which substitute the Mono-Register Annexes based on SharePoint Lists.
o Documents. The new Library in Dictionary term substitutes the Multi-Register Annexes
based on SharePoint Libraries.
o Groups of Fields. The Multi-Register Annexes based on SharePoint Lists can be substitut-
ed by Groups of Fields.
The following image shows the AuraPortal Structure with the FAMILIES panel outlined, where the configu-
ration of each of the Families can be accessed, as well as the Relations between Families functionality:
The Relations between Families is an AuraPortal characteristic that allows relating different AuraPortal Fam-
ilies to each other in a flexible, streamline and powerful way, to resolve the needs of most scenarios. There
are 3 types of relation: 1:N, 1:1 and N:N.
The Employees, Open Tasks, Accounts, Items, Projects and Areas families are explained in detail in the Del-
egated Administrator Manual.
The Business Rules family, the Own Families and the Relations between Families are explained in separate
Manuals which explain their characteristics in depth.
The Processes family is the subject of the present document.
The Documents and Annexes families are described in the Document Management documentation in the
Modeling series.

APPENDIX A2 - SECURITY: ACCESS CONTROL
The access controls to different parts of the application according to their characteristics and the permis-
sions held by visitors, operate in three fronts:
• Family Prefilters
• Authorizations in Classes (of Families)
• Secure Rooms
A2.1. Family Prefilters

The Family Prefilters control the data presentation a visitor will see in a Message or Task Form when he
must choose one or more relative options in a Family field. These filters restrict the elements that can be
chosen, avoiding this way that a visitor chooses elements outside his jurisdiction.
Unlike Authorizations and Secure Rooms, which are explained afterwards, the Family Prefilters are not
directly related to the visitors’ permissions or roles. They are just linked to the Term name (always a family
term) and therefore they’re defined in the Dictionary of Terms (Structure). More specifically, on creating a
Family type General term, the box Prefilter Yes is marked and the Classes and/or Elements to appear in
the filter are determined.
Let’s suppose for example that in the Dictionary of Terms, a ‘Client’ Family type term is created in the Ac-
counts Family. Once the term is created, it can be associated to a Family Prefilter defined in such a way
that it only shows the elements of the Clients Class of the Accounts Family (it won’t show for example the
elements of the Suppliers Class). This means that when the Form performer finds himself with the field
named Client and presses the search icon he will only see the Accounts Family and inside the Accounts
Family only the accounts that belong to the Clients Class. That’s logical since it wouldn’t make sense access
the complete list of all accounts, leading to a loss of time, excessive use of the server memory and privacy
elimination of the accounts that shouldn’t be accessible.
Another example: Let’s suppose that the term Minor Goods is created within the Items Family and then a
Family Prefilter is associated to this term, which only allows the Items Good A, Good B and Good C. When
the performer of the Form containing the field Minor Goods must choose a good for this field, the search
icon will only show the goods A, B and C, according to the Family Prefilter.
The Family Prefilters system allows that each different visitor (meaning each Form performer) only has ac-
cess to see and select the permitted Family elements.
Security is obtained when, on designing the Class of Processes and once known – for a certain object (Task
or Message Event) – which Role is the one figuring as the Form performer, the field is placed in the Form
based on the term of the Family Prefilter desired for this performer.
This means that, in the Dictionary of Terms there must be created as many Terms as the different Family
Prefilters wanted to be used in the application.
Note.
More information about Prefilters can be found in the Dynamic Forms documen-
tation.

A2.2. Authorizations in Classes
The access to elements of AuraPortal Families is controlled by means of Authorizations, just as explained in
the Delegate Administrator Manual.
The Authorizations are defined from Employees: Tree and Employees in Structure. Clicking on the Employ-
ee Groups button, groups of employees can be created for different uses, among which include the per-
missions in Classes to Create, Edit (modify) and/or Read the elements of the Employees, Open Tasks,
Accounts, Items, Projects and Areas families. The following image shows the window for assigning Class
permissions:
A2.3. Secure Rooms

The access controls to the different parts of the application according to their characteristics and the per-
missions held by the visitors, operate following the Access Control by Secure Rooms system, which is ex-
plained in this Document.
Broadly speaking, the system is based on the following definitions:
Protected Elements. They are the parts of the application that perform operations whose access by us-
ers must be controlled by a security system. The Protected Elements are protected by being virtually
stored in Secure Rooms.
Secure Room. Place that virtually stores an undetermined number of Protected Elements.
Security. Set of Secure Room requirements that give entrance to it to make operation in READ, EDIT
and CANCELLATION modes in the Protected Elements stored in this room.
Visitor. A user who tries to perform Read, Edit or Cancellation operations in a Protected Element, which
means he’s trying to enter the Secure Room the element is stored in. Possible visitors include Employ-
ees, External Users and Guest Users.
Permission. Group of titles given to a Visitor in order to pass through the Secure Room’s Security.
Guardian. System function responsible for comparing the Security of a Secure Room with the Visitor’s
Permission and consequently allow entrance or not, along with the relevant Read, Edit or Cancellation
permissions in the Protected Elements.

When a Visitor tries to perform an operation on a Protected Element in a Secure Room, the Guardian
looks for this Secure Room and after ensuring that the Validity Period is met, examines the Visitor’s
Permission and compares it with the Security of the Secure Room to determine whether access can
be granted or not.
_Open. A predefined Secure Room with no restrictions. It is applied automatically to all options that
require a Secure Room but none has been applied.
The Secure Rooms are created from the Dictionary of Secure Rooms in the AuraPortal Structure. See the
image below:
For full details about Secure Rooms, consult the Secure Rooms documentation.
APPENDIX A3 – BPMN MODELING: OBJECTS

The Modeling Objects in Standard BPMN 1.1 as applied in AuraPortal listed and shown next grouped in
their categories: Tasks, Subprocesses, Events and Gateways. The Artifacts are also Objects, although they
don’t intervene in the Processes flow.
A3.1. Tasks
The Tasks carry out the Process activities, either through human intervention (Personal Tasks) or through
the system (System Tasks). A Task can have various entrance connections but only one exit, except for the
Tasks with Inlaid Event that can have two exits: One, the Task normal one (not always required) and the
other from the inlaid Event (this last one is mandatory).

SYMBOL FUNCTION
Simple
Personal Task
Task carried out by a System User. There are three types of users: Internal
Users, External Users and Guest Users. Code: TP
TP.33
System task
Task carried out by the system. There’s a System task for each function to be
carried d out (Send a Notification, to one or various addressees, Start a Pro-
TS cess, Perform a Stored Procedure, etc). Code: TS
Compensation Task
Personal task that compensates or cancels the effects of the Task with Com-
pensation Event (TPC) it’s associated to in a Transaction (Transactions are
TPC.47
always Subprocesses with SPC code).
The Compensation Task is activated only when even though the Task with
Compensation Event (TPC) has been terminated successfully the Transaction
TC.37 it belongs to cannot be completed and has to be canceled, meaning it has
to go take (compensate) the actions already taken in the TPC Task. Code: TC
With Inlaid Event
Task with Inlaid Message Event

Has a Message Event inlaid. If the Message arrives before the performer
terminates the Task, it’s interrupted and the Process flow continues through
TPM
the inlaid Message Event exit. Code: TPM
Task with Inlaid Time Event

Has a Time Event inlaid. If the expected time arrives before the performer
terminates the task, it’s interrupted and the Process flow continues through
TPT the inlaid Time Event exit.
Code: TPT
Task with Inlaid Multiple Event

Has a Multiple Event (Message and Time Event combination) inlaid. If one of
the events is met before the performer terminates the Task, it stays inter-
TPX.61 rupted and the Process flow continues through the inlaid Multiple Event exit.
Code: TPX

Task with Inlaid Compensation Event
This Task, which must necessarily figure inside a Transaction (in the devel-
oped notation of a SPC Sup-process), has a Compensation Event inlaid that’s
associated to a Compensation Task (TC). Once the Task with inlaid Compen-
sation Event is terminated with success, if the Transaction cannot be com-
pleted, the system activates the Compensation Task associated for compen-
sating (cancel or move back) the actions already carried out in the Task with
Compensation Event (TPC) it’s associated to. Code: TPC
A3.2. Subprocesses
All the Subprocesses in Compressed Notation must contain a hyperlink that links each one of them to the
Start Event of their corresponding Developed Notation. The Developed Notation, which must be drawn in
another part of the Diagram, shows the details of the Subprocess objects and connections.
SYMBOL FUNCTION
SIMPLE
Subprocess
Group of Objects (Tasks, Other Subprocesses, Events and Gateways) that
for an independent operative unit within the Process. Code: SP
SP
Compensation Subprocess
Subprocess that ‘compensates’ the effects of the Task with inlaid Compen-
sation Event (TPC) to which it’s associated in a Transaction.
TPC.47
It’s only activated when the Task with inlaid Compensation Event (TCP) has
been successfully terminated but the Transaction (the Subprocess SC) it
belongs to cannot be completed and has to be canceled, which means it
SC must move back (compensate) the actions carried out using the TCP Task
by means of a Compensation Subprocess. Code: SC
With Inlaid Event
Subprocess with inlaid Message Event

If the Message defined in the inlaid Event arrives before the Subprocess is
naturally terminated, it’s forced to terminate immediately and the flow
continues from the inlaid Message Event exit. The Subprocess Developed
SPM
notation must be designed in such a way that it contains the necessary
logic for the mechanic described here to be met. Code: SPM
Subprocess with inlaid Time Event

If the time defined in the inlaid Event is met before the Subprocess is natu-
rally terminated, it’s forced to terminate immediately and the flow contin-
SPT ues from the inlaid Time Event exit. The Subprocess Developed notation
must be designed in such a way that it contains the necessary logic for the

mechanic described here to be met. Code: SPT
Subprocess with inlaid Multiple Event

Has a Multiple Event inlaid, which combines Message and Time Events. Its
function is the same as the one described above for the free inlaid Mes-
SPX
sage and Time Events. Code: SPX
Transaction
This Subprocess, which always has a Compensation Event inlaid, includes
the Objects and Connections that configure a Transaction. If this cannot be
completed successfully, the appropriate compensations must be carried
SPC out and the inlaid Compensation Event exit must be activated. Code: SPC
NOTE. This Subprocess developed notation must be correctly constructed
for the compensations to take place.
A3.3. Events
The Events control the current (flow) initiations and stoppages in the Processes.
• The Start Events initiate the (Sub)-Processes (they have no entrance and only one exit connec-
tion).
• The Intermediate Events detain the current in its position until the conditions defined when defin-
ing their own attributes are met (they can have various entrance but only one exit connection).
• The End Events terminate (Sub)-Processes or detain certain flow currents within the (Sub)-
Processes (they can have various entrance, but no exit connection).
A Process or Subprocess can contain various End and Intermediate Events. But it can only contain one Start
Event.
SYMBOL FUNCTION
Start
Message Start Event

Starts the Process on receiving the Message edited with the Form that’s speci-
fied in this Event attributes, or by a Process Start System Task. Code: IM (Invis-
ible)
Start Time Event

Starts the Process on meeting the time (any definition form: Day of the Month,
of the Week, Date, Hour, Minute, etc.) indicated in the conditions specified for
this event. Code: IT (Invisible).

Multiple Start Events
Contains any Message and Time Events combination. Starts the Process when
the conditions specified for one of the contained Events is met. Code: IX (In-
visible)
Subprocess Start Event

Start Event within the Developed Notation of a Subprocess. It’s activated as a
hyperlink of its corresponding Compressed Notation when the main Process
IS.60
current reaches this last one. Code: IS
Intermediate
Intermediate Message Event

Detains the current until receiving the Message edited with the Form specified
for this Event or by means of a Message Activation System Task, generally
EM
from another Process. Code: EM
Time Intermediate Event

Detains the current until the time specified for this Event is met. Code: ET
ET
Multiple Intermediate Events

Contains a combination of Message and Time Events. It detains the current
EX until one of the Events is met. Code: EX
Link Event
Sends and receives the current to or from another link, with which it maintains
EL the hyperlink. Code: EL
End
Current End Event

Indicates the Current (flow) end of a (Sub)-Process. When this Event is
reached, the flow of this thread stays permanently stopped but the flows of
FC.32
the rest of the threads continue their course. Code: FC
(Sub)-Process End Event

If the event is placed within the general Process, it forces the full termination
of the Process and the permanent cancelation of all the objects, including the
FN.73 unfinished Tasks and Subprocesses it may contain.
If this event is found within the developed notation of a Subprocess, the Sub-

process is terminated and its objects canceled. However, the general process
containing the Subprocess continues active until it reaches its own Process
End. Code: FN
Other
Point of Control
Takes (Time and other) samples in the moment the flow passes through it.
They’re used in Tracking. Code: K
A3.4. Gateways
The Gateways redirect the Process flows, diverting them to some threads or others.
The Divergent Gateways (accept only one Entrance) redirect the flow of their Entrance thread to some Exit
threads or others. The Convergent Gateways (accept only one Exit) group together all or some the cur-
rents of their Entrance threads into their unique Exit thread.
SYMBOL FUNCTION
Divergent
Exclusive Divergent Gateway (XOR)

Has one Entrance and various Exits. The Exits must be numbered in order to
establish the order they have to be examined in, since the first one to meet the
established conditions will be the one to drive the Process current. The rest of
the Exits will be disabled. Code: DX
Inclusive Divergent Gateway (OR)

Has one Entrance and various Exits from which one or more will be valid. The
valid Exits will create parallel currents in their own threads and the rest will be
disabled (will not contain current). Code: DO
Parallel Divergent Gateway (AND)

Has one Entrance and various Exits, all of them valid. Each Exit will create a
parallel current in its own thread. Code: DA

Convergent
Exclusive Convergent Gateway (XOR)

Has various Entrances and one Exit. When the first Entrance is produces, it drives
the current to the Exit and the rest of the Entrances stay invalidated. Code: CX
Inclusive Convergent Gateway (OR)

Has various Entrances and one Exit. The Gateway that knows which of the En-
trance threads have current and which no (depends on what’s occurred in the
Process upstream), waits for all the ones with current to arrive in order to allow
the only Exit.
Code: CO
Parallel Convergent Gateway (AND)

Has various Entrances and one Exit. All Entrances must have current threads, so
the Gateway will wait for all Entrances to arrive in order to allow the only Exit.
Code: CA
Collector (OR)
This Gateway is always open. Its mission is to redirect whichever Entrance to its
only Exit at the moment the current passes through it and can be used for mak-
ing reading the Diagram easier. It’s necessary to be used as a previous assembler
when various threads must reach an Object that only accepts one Entrance (like
with the Divergent Gateways DX and DO).
Code: CL
A3.5. Gateways (Special Notation)

This notation can be applied to all the Gateways when the number of Exits in the Divergent or Entrances in
the Convergent is greater than 3. As seen in the image, there can be used up to 7 Entrances/Exits and, from
each one of them, there can Enter/Exit al the current threads wanted. The circles included represent each
object, being a Task, Subprocess, Event or Gateway.

A3.6. Artifacts
The Artifacts are complementary elements that help understanding the Diagram. Their function is illustra-
tive and not executive; therefore, the Engine doesn’t take them into consideration when executing the
Processes.
Besides the symbols described below, it is also possible to insert (paste) any externally created image on
the canvas.
Note.
The symbols in the following image are those that appear in the AuraPortal Helium
Modeler and may vary slightly in the Visio Modeler.

FUNCTION
Bands (1)
The Bands are used to outline parts of the diagram, for example a set of objects that affect a specific de-
partment, etc.
Business Rules (2)
To insert the representative icons of the different types of Rules (Textual, Assignation, Calculation and In-
ference). It doesn’t influence the Process execution.

Adapter (3)
This connects to external applications, like ERP, CRM, etc., to read, import or export information from the
Process. The connections with this Object are represented by trace lines.
Title (4)
To insert a title outlined in a frame.
Note and Text in Post-it (5)
The Note is an explicative text in a part-frame with a pointer. It can connect to another Object from the
pointer end.
The Post-it is a text shown as if it was a post-it. The square’s dimensions can be adjusted at will. It can
connect to other objects if necessary.
Free Text and Text in Frame (6)
The Free Text allows inserting a free text in the Model. As in the rest of the Artifacts texts, both the letter
type and its size and attributes can be modified. It cannot connect to other Objects.
The Text in Frame is a text appearing in a square with a solid background of the desired color. The square
length can be chosen and then the height automatically adapts to the size of the contained text. It can
connect to other objects if necessary.
Dialog (7)
To insert a rounded, empty frame with just a border, to outline text or other artifacts.
AuraPortal Logo (8)
The program’s corporate logo.
Lines (9)
To draw straight lines inside the Model. They’re independent auxiliary lines with no possible connection
with Objects.
The Helium Modeler Manual includes all the necessary information for building the Class of Processes
Diagrams.


Modeling 01 BPMProcesses Introduction Helium 20180928 PDF

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Modeling 01 BPMProcesses Introduction Helium 20180928 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Modeling

BPM Processes. Introduction

2. LIFE CYCLE OF THE PROCESSES ......................................................................................................................... 7

3. CLASS OF PROCESSES .......................................................................................................................................... 9

4. EXAMPLE OF MODELING ..................................................................................................................................... 89

5. EXAMPLE OF EXECUTION .................................................................................................................................. 128

MODELING. BPM PROCESSES. INTRODUCTION Page 2 of 160

6. EXAMPLE OF MONITORING................................................................................................................................ 136

APPENDIX A1 - AURAPORTAL AND PROCESS STRUCTURE ............................................................................ 141

APPENDIX A2 - SECURITY: ACCESS CONTROL .................................................................................................. 148

APPENDIX A3 – BPMN MODELING: OBJECTS ..................................................................................................... 150

MODELING. BPM PROCESSES. INTRODUCTION Page 3 of 160

Competitive and Economical Advantages

MODELING. BPM PROCESSES. INTRODUCTION Page 4 of 160

Three Steps in BPM

Drawing a diagram of the process model.

Some examples of processes:

MODELING. BPM PROCESSES. INTRODUCTION Page 5 of 160

Projects of any kind.

MODELING. BPM PROCESSES. INTRODUCTION Page 6 of 160

Here is a brief description of each one:

MODELING. BPM PROCESSES. INTRODUCTION Page 7 of 160

AuraPortal offers two different complementary types of simulation:

- Delegated Administrator Manual

MODELING. BPM PROCESSES. INTRODUCTION Page 8 of 160

This model is subsequently applied to all the Processes in this Class.

MODELING. BPM PROCESSES. INTRODUCTION Page 9 of 160

MODELING. BPM PROCESSES. INTRODUCTION Page 10 of 160

The details are explained below.

3.1. General Data

- Stage 2. OBJECTS. Assign the defining attributes to each object.

The General Data page is explained in detail below.

MODELING. BPM PROCESSES. INTRODUCTION Page 11 of 160

• Keep the data from the simulation as real data.

MODELING. BPM PROCESSES. INTRODUCTION Page 12 of 160

This includes two options:

MODELING. BPM PROCESSES. INTRODUCTION Page 13 of 160

3.1.2. Identity Section

The full Identity section contains the following fields:

Process Identification: Base Reference

MODELING. BPM PROCESSES. INTRODUCTION Page 14 of 160

▪ The Key provided on creating the Class is PE (Process Example)

▪ The ID № provided by the system is 34

With all this, the code of the Class of Processes is:

Class of Processes Code = EP34.1

Base Reference = EP34.1_1

Work = Jeresa Sports Airport

Investment Object = Control Tower

In that case the Extended Reference of this Process will be:

Extended Reference = EP34.1_1_Jeresa Sports Airport_Control Tower

MODELING. BPM PROCESSES. INTRODUCTION Page 15 of 160

Generate Descriptive Document (2)

Generate Detailed Document (3)

MODELING. BPM PROCESSES. INTRODUCTION Page 16 of 160

MODELING. BPM PROCESSES. INTRODUCTION Page 17 of 160

MODELING. BPM PROCESSES. INTRODUCTION Page 18 of 160

MODELING. BPM PROCESSES. INTRODUCTION Page 19 of 160

MODELING. BPM PROCESSES. INTRODUCTION Page 20 of 160

MODELING. BPM PROCESSES. INTRODUCTION Page 21 of 160

Going back to the IDENTITY section…

MODELING. BPM PROCESSES. INTRODUCTION Page 22 of 160

Description. An optional description of its function.