Process Models

1. Plan Appian Process

Appian applications are record-centric, which means that the core of each application is data structured
using several Record Types that give a 360-degree view of a business.
Record-centric applications are not designed to keep data in the process, but instead data should be
saved to a Record’s data source as soon as possible.
This impacts how you design both your application and its processes. Plan your application around
Record Types and Record Actions.

When you run a single process instance, all data captured by this process model (process variables, task
properties, additional metadata, etc.) is stored in memory. However, as with all software systems, Appian
platform is configured with finite resources for storing data. So, its important to build Appian process in
the way that conserves the amount of space these processes take up in system memory.

Appian recommends
- building shorter processes or
- building longer processes in a modular fashion, using start processes and subprocesses to break up
longer workflows.
- using limited number of nodes and process variables
- configure tasks to expire or get reassigned after a time of inactivity
o include cancellation flow for User Input tasks to ensure the process ends when cancelled, or
form not submitted
o include time exceptions to User Input tasks to ensure the process is not long-living, and
ends even if User Input task is not completed

This way the data will be saved to the database quickly, without keeping it in the processes for a long
time.

Short processes have limited number of nodes. Process models with a large number of nodes have a
larger memory footprint.

You can save time creating processes in Appian by creating simple processes form a Record Type by
clicking Generate a Record Action option. This can generate Record Actions for 3 common use cases:
- Create (adding a record)
- Update (updating the record)
- Delete (deleting the record)

Along with Record Actions Appian will auto-generate default process models, interfaces, and other
objects needed for the entire workflow to work.
As the developer you can take the default process models and extend then using additional nodes and
smart services available in the process modeler’s palette.
Quiz

Question 1

Question 2

Question 3

Question 4
Question 5

2. Design Appian Process (Process Model)

In Appian Designer you can create a Process Model from an Explore or Build views.

You can create a Process Model from scratch or duplicate an existing Process Model.

Appian recommends naming Process Models using the following naming convention:
 Start the name with the application prefix
 Then use title casing and spaces to separate words (for example, “AS New Vehicle”, where
“AS” is the application prefix)

You should always provide a short description too; this will ensure knowledge sharing across the
team.

2.1. Security
Processes are saved in folders, but unlike other folder-ed design objects Process Models DO NOT
inherit from their parent folder. Each Process Model must be secured individually.

A user must have at least Initiator permissions to start a Process Model.

Like other application objects, you should always use groups rather than individual users to configure
Process Model security.

Security permission levels:

  Administrators: can fully edit the Process Model, modify security setting and delete it. It’s
the highest permission level. Use it only for the developers in change of the Process Model
object.
 Editor
 Manager
 Viewer: can view and start the Process Model but can’t make any changes to the design
object.
 Initiator
 Deny: is used in instances when a sub-group of application users is nested within a group
with a higher permission level. It explicitly denies access to the Process Model.

Administrator and Viewer are the key permission levels. The last user who saved/published the
process model is always the designer of the process model.

The following table outlines the actions that can be completed for each permission level in a process
model's security role map:

Actions Administrator Editor Manager Viewer Initiator

Start the process model* Yes Yes Yes Yes Yes
View the process model Yes Yes Yes Yes No
View process model reports Yes Yes Yes Yes No
Override task assignment (whether or Yes Yes Yes No No
not reassignment is allowed)
Update the process model Yes Yes No No No
Save the process model Yes Yes No No No
View the process model Yes Yes No No No
documentation
View the security Yes No No No No
Update the security Yes No No No No
Delete the process model Yes No No No No
Override another user editing the Yes No No No No
process model
Publish the process model Yes No No No No
*Users must have at least Initiator permissions to the process model in order to execute the Start
Process smart service successfully.

If a user or group is assigned the Deny role, they cannot perform any action associated with the
process model.

Quiz:

Question 1
Question 2

Question 3

Question 4

Question 5
2.2. Process Modeler
When you create your Process Model in will be opened in the Process Modeler. By default, the
canvas will contain the connected Start and End nodes.

The Process Model will be opened in the Designer View, by default. This view is used to configure
and publish executable Process Models, which means that you can fully configure each node in the
process.

Analyst View is used to create high-level diagrams, and it’s helpful when you want to mockup a
process, for example, to share mockup with the project stakeholders. You can add nodes to the
process without configuring them and the process won’t alert you about missing configurations.
The main sections of the Process Modeler are:
 Canvas is used for adding nodes and smart services to a Process Model. To add nodes to the
Process Model you will search for them in the Palette.
 Palette contains all workflow nodes and Appian automation smart services needed to build
the process.
o Workflow nodes include:
 Human tasks (assigned tasks)
 Activities (run automated activity)
 Events (start or end the flow)
 Gateways (modify the direction of a flow in the process)
o Appian automation smart services are specialized business services and are key
low-code capabilities of Appian. Each Smart Service is like a mini-app that allows
you to add a piece of sophisticated functionality to a process. Smart services are,
by default, unattended, meaning the activity will execute once activated.
o You can use Search option to find specific item or expand the corresponding
category folder
 Menu includes standard command and the commands needed specifically for process
modelling:
o File:
 Save and Publish: generates the new version of a Process Model. The last
user who saved/published the process model is always the designer of the
process model.
 Versions: to view previously published versions and revert changes
 Start Process for Debugging: is used to debug processes.
o Tools
 Generate Documentation: generates process documentation
 Toolbar contains tools for managing Process Models
o Annotations are used to add notes to Process Models. There are helpful when you
want to call out sections that need additional explanations.

o Swimlanes define who performs a specific activity in the process

o Properties (can also be accessed from File -> Properties)

There is NO AUTO-SAVE, so save frequently while building Process Models.

Quiz

Question 1
Question 2

Question 3

Question 4
2.3. Process Model Properties
Accessible from Menu -> File -> Properties or from the Toolbar

Once you create a Process Model you should start by configuring the Alert and Data Management
tabs.

Alerts tab specifies who receives an alert if a process instance runs into an error. If the default
setting is kept, the alert will be sent to the System Administrarors.
Appian recommends sending these alerts to the corresponding application’s Administrator group.
Data Management tab is used for archiving or deleting processes. Each time a process is started, a
process instance is created. All process instances including completed and cancelled ones are
retained in memory until they are archived or deleted.

The instances must be cleared out periodically or else they can slow down system performance. By
default, processes are set archived 7 days after they are completed or cancelled. Appian
recommends archive processes after 3 days.
In any case whether you archive or delete, your choice must be dictated by your organization’s data
retention policy.
Archiving a process frees system memory but impacts your reports. The data in archived processes
are no longer available for reporting purposes.

Unlike archiving that saves data for future auditing, deletion removes data completely.

Deadlines tab is used to set the target date and time for completing the process. It is used to trigger
an escalation for task that hasn’t been completed.

Quiz

2.4. Start Form and Process Variables

Whenever a process starts with user completing a form you should setup a Start Form. You can
select from already existing Interfaces or create a new one
After the Interface is selected, Appian will suggest to automatically create process parameters to
match Interface’s rule inputs.

Process parameters are variables that receive values at the beginning of a process. These values can
come from a Start Form but also from other places.

The main advantage for Rule Inputs is that they can easily pass data between Process Models and
Interfaces, and you can use them as variables that capture response from the form. After you map
Rule Inputs to Process parameters, you will be able to transfer values from the Start Form directly
into Process variables.

Process variables capture data throughout the whole process and carry it from one node to the next

Process Variables tab lists all process variables of the process.

Activity Class parameters are Node’s Inputs and Outputs. These variables are unique to a specific
node. They work like local variables. You need to save them into the Process variables, if you want
them to get passed to the next node in the process.

Appian recommends that each process instance has a dynamic Process Display name, so that in
production the support team can easily differentiate between process instances. This is the name
that appears in the Process Activity tab of Monitoring view, which is used to monitor and
troubleshoot processes.

By default, the Process Display name is identical to the name of the Process Model. To create
dynamic Display name, use Expression Editor. Appian recommends using Process name and business
relevant values help by the process variables.
When you Save and Publish, the Process Model automatically validates that it’s configured correctly.
If not, the error message appears in a dialog, or at the bottom of a Process Model.
You have to fix these errors before continuing to debugging.

When debugging:
 the blue highlight means that the nodes completed without issue.
 Active nodes are colored in green
 If the node fails, it is outlined in red
 go to Process Details -> Variables tab to check if the data was captured correctly.

Debugging is an iterative process; you should debug a process model each time after adding each
individual node.

Each time you publish a process model, a new major version is created. All versions of a process
model, regardless of their status, are available for viewing and editing (depending on your security
settings). All new processes start from the latest major process model version.

Quiz

Question 1

Question 2
Question 3

Question 4

Question 5
Question 6

2.5. User Input Task

This node allows to assign form-based tasks to users. Use Form tab to add an Interface to the User
Input task.

Appian recommends setting Task Display name to be dynamic for User Input tasks, it helps users to
differentiate between tasks.

When you add an existing form to User Input task, Appian will suggest to automatically create Node
Inputs to match the Interface’s Rule Inputs.
If you edit Rule Inputs later in the Interface, you have to go back to this tab and click Refresh to
update de Rule Inputs.
To pass the values from node inputs to the next node, you need to save them using process
variables. Use Data tab to map node inputs to process variables.

Value filed is used to display data in the interface and Save Into filed is used if the user enters new
data and you want to save it back to the process.
Save Into field is only used with User Input tasks.

Assignment tab is used to assign the task to the person or group of people responsible for
completing the task.

Tasks have a potential to live for a long time if a user doesn’t complete the task. To avoid it, you
must always configure either Exception or Escalation.
 Escalation remains the task active, but it is reassigned to another group of users, or a
reminder to the original task owner is sent.

 Exception allows you to skip the task and move to the next step.
You can activity-chain tasks together in your process model if the completion of a task in a process
requires the same user to complete a subsequent task.

Quiz

Question 1

Question 2

Question 3

Question 4
Question 5

2.6. Gateways
Gateways control the workflow in the process models. They are decision points that adjust the path
of a process flow based on conditions you set. They allow you to evaluate different criteria to make
decisions on which path(s) your workflow should follow – as well as how many instances are allowed
to follow each optional path.

In Appian you can use 4 types of gateways

 XOR gateway is used most frequently. It splits a single incoming path to multiple outgoing
paths based on conditions you set.
 AND gateway is used to split a single path into multiple outgoing paths. It doesn’t have any
“if” condition, so all paths will execute.
o It is commonly used when you need to do something in parallel.
o It can also be used to collect all path into a single one, in this case the process will
not continue until all incoming paths reach the AND gateway.
 OR gateway is similar to AND, but with one key difference. It can split a single path into
multiple outgoing paths, but only paths that satisfy specific conditions will execute (that
could be one, many or all)
 Complex gateway is used very infrequently. It selective accepts incoming paths and
evaluate conditions to determine which paths should continue.
To configure gateways, use the Decision tab and direct the flow using process variables.
Add labels to the gateway’s connectors. Debug all paths to ensure they work correctly.

Quiz

Question 1

Question 2

Question 3

Question 4
Question 5

2.7. Scripts Task and Write Record Smart Service

Script task allows to perform an automated activity. Typically, this involves
- using an expression or rule to manipulate or query data
- evaluate a decision to determine how the process will progress
Typically, Script Tasks are configures using Node Outputs.

Write Record Smart service and Delete Record Smart Service allow you to add, update or delete
data in the database table associated to your Record Type, and then automatically sync all changes in
Apian. Write Record Smart service can only be used with records that:
- get data from database table and
- have Data Sync enabled
Configure this smart service using Data tab and use the Outputs tab to pass the primary key value
back into the process.

If a Record Type uses different data source or does not have data sync enabled, use Write to Data
Store Entity smart service.

Elevate permission for the Write Record Smart service node, select “Run as whoever designed this
process model” in the Assignment tab, to ensure it executes always, even if the business user gets
deactivated or a process doesn’t have an active initiator (for example, if it runs on a timer).
You can update only one Record Type at a time. If you need to update several related records,
update the base record first, and then update the related records using additional Write Record
Smart service nodes.

Sync Records Smart service is used to immediately re-sync your data in a workflow. It can re-sync
specific records in your Record Types, including those that use a Web Service as the data source.

Prefixes used in Process Model’s expressions

Prefix Data Level
pm! Process model properties Process
pp! Process properties Process
pv! Process variables Process
ac! Activity class parameters Node
tp! Task properties Node
msg! Message properties Node

Actor Properties
Function Name Description Syntax
Process Designer Returns the user that designed the process (the user who pp!designer
published the latest version of the process model).
Process Initiator Returns the user who started the process. pp!initiator
Task Owner Returns the single user who has accepted the task. For tasks tp!owner
that are assigned to a single user, the user automatically
accepts the task when it is first viewed.
Task Owner's Returns the user who is the supervisor of the task owner. supervisor(tp!owner)
Supervisor
Task Assignees The users who have been assigned the task. tp!assignees
Quiz

Question 1

Question 2

Question 3

Question 4
Question 5

2.8. Start Processes and Subprocesses

When building Process Models, it’s a best practice to keep process models short. You can break
longer workflows using Start Processes and Subprocesses.

Subprocess Start Process

 runs on the same engine as parent  runs on the engine with the lowest
process memory usage. If performance is a
 runs synchronously or asynchronously. consideration, Start Process is almost
If you need parent process to wait always the best choice.
until all activities in the child process  Only runs asynchronously
have completed, select a Subprocess  Use Data tab to configure Start
and configure it to run synchronously. Process node
 If your process has a functionality that
is tricky to debug, select a Subprocess
over Start Process
 Use Setup tab to configure Subprocess
node

When an asynchronous subprocess is started, the parent process flow does not wait for the child
process to complete. The flow continues without pausing.
 Process variable values can be transferred to the child process, but they cannot be passed
back to the parent process.
 Asynchronous subprocesses are useful in situations when related activities do not need to
communicate back to each other.
 They do not allow activity-chaining into a child process from the parent process.

When a synchronous subprocess is started, the parent process flow waits for the child process to
complete before continuing the flow.
 Synchronous subprocesses allow you to transfer data back and forth between parent and
child processes.
 They do allow activity-chaining into a child process from the parent process.

Common use cases for Subprocesses and Start Processes:

 Isolate multiple touches or approvals from different users. The main process will be easier
to grasp at a glance and you’ll avoid creating long-living processes.
 Isolate integrations. Integrations can be fragile, and the main process will be easier and
faster to troubleshoot if the integrations steps are isolated.
 Isolate steps that are launched using a timer or a rule event. This way you won’t keep the
main process active.
  Isolate generic steps that can be reused across multiple process models (for example,
standard approval or compliance process)

Quiz

Question 1

Question 2

Question 3

Question 4
Question 5

2.9. Troubleshooting Process Models

Save and Public your Process Model before debugging. During this step the Process Model will
automatically validate if it has been configured correctly. If there is any issue, Publish Errors will be
display in a pop-up dialog or below the process model.

Publish issues must be resolved before you proceed to debugging. If a process model does not pass
validation, you can save it, but you cannot publish it.

Process models need to pass validation and be published before users can execute them in an
application. This does not, however, prohibit process model designers from running a process for
testing purposes, which can be done in debug mode any time you save it.

Common error:
 Attended nodes are not assigned to specific user groups:
o Go to the Assignment tab and assign it to specific group
 Data not captured: an issue like that won’t throw an error, that is why you should always
check the Variables tab in the Process Details after debugging a node. This typically means
that the data wasn’t mapped to the process correctly.
o Go back to the node where the data is supposed to be captured and check if it is
saved correctly.
o If the node is configured correctly, double-check the form linked to the node: each
field must have values in the Display Value and Save Input To fields. To avoid this
issue always test the form independently of the process.
 Data not written to the table with Write Records Smart service
o Double-check the configuration of the Records input
o If it’s configured correctly, make sure that you are capturing all the necessary
values prior to reaching Write Record Smart service
o Additionally, check that the data is written correctly into the target table in the
database
 Write Records Smart service inserts an extra row instead of updating an existing one
o Most likely, the record passed to the node doesn’t have a value set for the primary
key
o To fix this issue ensure that whatever method is used to select the record is
supplying your process with the primary key.
o If the update is happening in the same process after the new row is created, ensure
that you are saving the node data “Records Updated” into the process variable

Start investigating process errors by going to Monitor View of the Appian Designer, and then
navigate to Process Activity tab.
For addition details, click the process instance and go to Variables or Errors tab in the Process
Details.

Alternatively, you can click the error, which will link you directly to the Errors tab. If you are in the
group that receives alerts, the alert email will link you directly to the error message.

Having a dynamic display name for the Process Model makes it easier to differentiate between the
process instances.

For additional information go to docs.appian.com and review the following pages:

 Process Errors
 Troubleshooting Process Models
 Monitoring and Editing Processes

Guidance
During development, process model warnings should always be addressed, and recommendations
should be addressed or dismissed depending on your use case.
Guidance is only visible for the latest published version of a process model or its latest draft. It is also
only visible in the Process Designer View, or in the Edit Mode of an active process (by clicking
the validate button).

Process model guidance is also visible on the Health Dashboard outside of the Process Modeler.
Process models must be published in order for their design guidance to appear on the Health
Dashboard.
Quiz

Question 1

Question 2

Question 3

Question 4
 Question 5

3. Surface a Process to Business Users

There are many ways to start processes in Appian, but most commonly processes are triggered by
business users. There are two main approaches to surface these types of processes to business users:
 Use process model to create a record action (record list action or related action), and then add
Record Type page to the Site. This option is used when business users work in the context of a
record list
 Add stand-alone Action Type page to the Site. This option is used when business user needs to
initiate a new request but doesn’t need to take any further action on it.

2.1. Add Record Type page to Site

In Appian you can quickly generate Record Actions from a Record Type for three common use cases:
 Adding a record
 Updating the record
 Deleting the record

The key difference between Record List action and Related action is the context, it passes values into the
Process Model’s parameters. When the process starts as a Related Action it needs the data form an
existing record. To pass this data into the process use an expression.

You also need to add the Related Action to the Summary View of the Record Type, so that it appears to
business users.
The final step is to add Record Type page to the Site. This page will provide business users with access to
the record list of a specific Record Type.

2.1. Add Action Type page to Site

Business users need Viewer privileges for both the Site and the Process Model in order to view the page
and complete the form.

Quiz
Question 1

Question 2

Question 3

Question 4

Question 5
4. Write Data with Custom Data Types
Custom data types, also known as CDTs, allow you to structure and write data to your database.

2.1. CDTs and Data Store

A custom data type (CDT) is a user-defined data object that structurally mimics the logical grouping of
related data created within the table of your relational database. It, along with the data store, is what
allows you to structure and write data to the database

The Data Store is the connection that communicates changed record data from a CDT to a relational
database. Application needs only one Date Store for all tables in the data source and multiple CDTs (one
for each table)

CDTs are created in Appian as supporting objects when creating Record Actions for the purpose of
writing data to a database. CDTs can also be created independently from creating a Record Action.

CDTs vs Record Types

Record types with data sync enabled are an efficient, performant way to query and relate data from
different tables. They also allow you to use record variables to update, insert, and delete data from
database tables. If your application uses record types without data sync enabled, you need to use CDTs
instead of record variables when updating, inserting, or deleting data from database tables.

Quiz

Question 1

Question 2

Question 3

Question 4
2.1. Create CDT and Data Store
There are five different ways to create CDT:
 Automatically when you create a Record Action: If you have a database table with data sync
enabled as the source of your record type, Appian can automatically generate common record
actions for that record type using basic information you provide. The generated action uses
existing objects or creates new objects to meet the object requirements.
 From existing database table: Use this option when you have an existing table in your database
and need to create a CDT in order to write to that table within Appian.
 From Scratch: Creating a CDT from scratch will require you to add each data field and configure
the parameters including: name, type, length, array and key.
 Duplicate existing CDT: You can use this option when you need to make a CDT that is similar to
another CDT. All existing configurations on the original CDT, including any JPA annotations, will
be duplicated. For example, if the original data type is mapping to a database table called Vehicle
using the @Table annotation, the new data type will also map to the Vehicle table.
 Import XSD: Use this option if you have an XSD file that defines your CDT. You may also create or
edit multiple data types at once by importing a single XSD file that contains multiple data type
definitions.

Creating a CDT and data store from scratch

It is a best practice to include application prefix as part of the CDT’s Namespace. The combination of CDT’s
Namespace and its Name will uniquely identify this specific CDT and differentiate it from other similar
CDTs across environments or objects.

CDT’s Name doesn’t contain spaces but underscores to make it easier to reference CDTs in expressions.
Appian recommends the following naming convention: start by application prefix, underscore and use
Pascal Casing for the rest of the Name without spaces (for example, “AA_Part” where “AA” is the
application prefix)

Description is also important because it allows other developers to know what this specific CDT is for.
CDT Name and Namespace CANNOT be changed once created.

Add CDT fields manually, use Camel Casing for the field names. All CDTs referenced in a Data Store must
have a Primary Key.

CDTs are unlike any other design objects because they are secured at the level of the objects that use
them. For example, if an interface calls a custom data type, then the interface’s security is applied.
Additionally, only System Administrators and Designers can perform actions on custom data type.

The following table outlines the data type actions that can be completed by each:
Actions System Admin Designer
Create and edit the data type Yes Yes
View the data type Yes Yes
Download the data type’s XSD Yes No
Delete the data type Yes No

Creating a CDT and data store from an existing table

Once you select Data Source and Table or View, you will still have to change CDT Namespace. You can also
adjust its Name and fields’ names.

You can also remove some fields if your business users don’t need a particular assignment of data. This
won’t change the database; you will simply be connecting to some but not all columns.
Below the fields list, you will also see the option checked to connect you CDT to the Data Store and Data
Store Entity.
If you already have a Data Store in your app, you likely don't need to create another one unless you want
to connect to multiple data sources. However, you will need to update the data store each time you
connect it to a new table for writing data.

Remember, record types can generate the data store object automatically when creating record actions,
and this is the preferred method.

Create Data Store

Make sure that All Users group of your application has Viewer permissions on the Data Store, this will
ensure business users can update data they are supposed to have access to.

Adding Data Store Entity to the Data Store will allow to map CDT to its table in the relational database.

When you click “VERIFY”, Appian checks whether the connected database contains the table with the
same structure as CDT. If the table doesn’t exist, Appian will create it automatically when you click “SAVE
& PUBLISH”.

You must “SAVE & PUBLISH” you Data Store each time new Data Store Entity is added to the Data Store.

Quiz

Question 1

Question 2
Question 3

Question 4

Question 5
2.1. Edit CDT
As you work on your application, you may need to edit your CDTs. While CDTs are editable, it is
important to remember that your approach to editing CDTs will differ from other design objects. This is
because CDTs are connected to external database tables that likely need to be managed separately.

Before updating your CDT, use the Dependents view to determine where exactly the CDT is used and the
exact impacts your changes may have.

Adding Fields
You can add a new field to your data model simply by adding a new field to the CDT. Once you make the
change, you'll need to verify your table mappings and re-publish the data store.
This will add a new column to the connected table.
Lastly, to query data from that field for viewing in records and reports, you need to update the record
type data model.

Editing Fields
By far the most common editing method is to make the change directly in the database column first.
After that, you’ll need to go back to your CDT to download the XSD file.
Complete the edits directly in the file, and then create a new version of the CDT from the updated XSD
file. This approach is preferred by Appian developers because it provides more control over CDTs.

To learn how to edit the XSD file, go to the Appian Documentation, search for the Custom Data Types
page, and review the steps for various editing workflows.

Quiz

Question 1
Question 2