Appian Training
TIPS & TRICKS
This document contains tips and tricks for Designers. Refer to these resources when building
applications.
AGILE DEVELOPMENT
Appian uses and recommends an Agile delivery methodology as it is the best way to ensure speedy
delivery of value. Agile is an umbrella term that describes a growing list of methodologies that all
support the same principles and goals of speed, quality, adaptability, and transparency.
Agile methodologies are based on incremental and iterative delivery. Value is delivered throughout
the project as opposed to only at the end. This reduces risk by creating more feedback loops at
every stage of development. At the end of each increment, also known as a “sprint,” a finished
product (even if minimally capable) is delivered. Designers prioritize work in a backlog, and organize
the backlog by highest value first. Each item is scored with a relative difficulty rating, known as
“sizing,” and that helps designers choose which items to accomplish from the backlog in each sprint.
It is important to remember that the goal of each sprint is to deliver a functioning product, not to
complete a phase of traditional project management methods. Each sprint includes the planning,
development, testing, and delivery of a function or feature. Agile practitioners aim to produce the
items with the highest business value first. Once a viable product is delivered, improvements are
taken off the backlog to increase functionality of already delivered products. Again, this is done in
order of highest business value first.
2
AGILE DEVELOPMENT
Methodology in Class
While a typical Agile sprint is anywhere from two to eight weeks, the condensed timeline of Appian
training courses call for daily cycles. Students should use their experience in class to prioritize each
feature of their project, estimate the difficulty, and select work to be done on each day. Appian
Training suggests focusing on delivering a minimum viable product (MVP) that meets the minimum
requirements of the project first, and then prioritize “nice to have” features on the backlog to be
worked on as available.
To help with this prioritization, Appian utilizes story mapping. A story map helps designers visualize
key deliverables and arrange them. Major capabilities, or goals, are listed across the top. Supporting
functions are listed below those, known as the “spine.” Below each item in the spine is the
supporting subtasks that enable the supporting function. The further downward a task, the less
important it is for the release. In this way, designers can prioritize the most important features and
functions first, and visualize what they can save for later when there is time. The example below
shows an example story map for an email application.
Necessity
Organize
Email
Manage
Email
Manage
Calendar
Time
Search Email
File Emails
Compose
Email
Read Email
Delete Email
View
Calendar
Create Appt
Update Appt
Search by
Keyword
Move Emails
Create and
Send Basic
Email
Open Basic
Email
Delete Email
View a List
of Appts
Create basic
appt
Update
Location
Create
sub-folders
Send RTF
email
Open RTF
e-mail
View
monthly
formats
Create RTF
appt
An initial release may include a subset of key functions from the spine and subtasks, but not all. As
time goes on, and more tasks are completed, designers and planners may find that improved
functionality is not needed or desired. At that point, designers have wasted no time developing
features that do not have value, and can move on to other important elements.
3
APPLICATIONS
An application is a collection of objects that represents a business solution. An application
functionally groups design objects together to form the user interfaces, logic, processes, and data
your users will interact with while doing work in Appian. This container can also be shared or
moved from one environment to another.
Each application has several properties associated with it. Of particular interest is the name of the
application, a short description, its associated actions, and whether or not it is published.
Name
The name of the application that will be visible to users in Tempo
Description
A description of the application visible to other designers
Published
Determines whether or not an application’s news feed items and
actions are visible in Tempo, does not affect record or report
visibility
Actions
A list of designated processes that users can initiate from the Actions
tab when the application is published, processes are not
automatically considered application actions unless assigned as such.
Application
Objects
Objects are bits of
self-contained logic that can
be referenced from another
object. Individually, they
may be an interface, a static
value (or list of values), a
business rule, or others.
Think of them as building
blocks used to construct an
application (which itself is a
type of object). The
following image illustrates
the relationship of objects
to one another.
4
APPIAN DATA INTERACTION
This diagram explains the flow of data within Appian
5
APPLICATION CHECKLIST
This checklist serves as a notional path a Designer can take when building an application. There are
numerous ways to effectively build applications, but the way outlined below follows the sequence
used in class.
Application Creation
1. Log in to the Appian Designer environment.
2.
Click New Application.
3.
In the Name field, type the name of your Application.
4.
In the Description field, add a short description.
5.
Click Create.
Application Setup
1.
2.
3.
4.
5.
Administrator Console - click Users and create your individual users.
In the Application Designer, create your Groups. All applications should have at least two
groups (Administrators and All Users). Make All Users the parent-level group for all other
groups; set the Administrators group as the role of Administrators for the All Users group.
Create your Custom Data Type(s) (CDT), ensure you use an auto generated primary key.
Create any Constants you know you will need (you will create more Constants as needed
during the application building process).
Create any Expression Rules you know will need.
Process Modeling
1.
Create your first Process Model. Generally this is the process to create the base record of
objects or items such as customers, vehicles, positions, etc. Remember to set applicable
security - Admin group serving as Administrators, the group(s) performing the action as
Viewers or above. Remember to set your Data Management policy, Alerts, and Process
Variables in the Process Model Properties tab.
2.
Build your first interface to fit within your first process model. Generally this is the add new
item or object as per the Process Model.
3.
Create your Data Store Object. Once created, click Add Entity to connect your CDT to the
Data Store. Click Verify and Save and Publish.
4.
In your process model, add a Write to Data Store Entity node and configure it to match your
newly created Data Store.
5. Thoroughly debug your process model to ensure all data is effectively captured from the
interface and successfully stored in your Data Store.
6.
With your Data Store structure in place, create your Query Rules. Generally it is good to
have a query to retrieve all the items and another to retrieve a single item by id.
6
APPLICATION CHECKLIST
Document Management
1.
If your application will require file uploads or documents, create your Knowledge Center.
2.
Create at least one Document Folder to hold your uploaded files. Set applicable security on
your Knowledge Center. If required for different types of files, create multiple folders.
Entity-Backed Record
1.
Create a new Record Type. Set appropriate security.
2.
Identify the source of your Data (your Data Store and CDT table)
3.
4.
5.
6.
7.
Set your Default Filters and User Filters.
Select Edit Record List and configure the record columns and data displayed.
Enter a value for Record Title (this will be essential if you plan to use News posts with
Record Tags)
Add a Summary View. You will need to create a new Interface with read-only components to
serve as the summary view.
Related Actions. Create at least one related action. For example an update the Record
action is common.
Main Process Model
With your first process and related action created, design your main process model. This will
involve the creation of new interfaces and decisions around how you wish to use and manipulate
data. Debugging after the addition of each new node in your process is strongly recommended.
Reports
The way your data is structured will determine how you create different types of reports. If you use
a nested CDT, you will not be able to use the Report Builder wizard in the interface designer, and
will need to build your reports from scratch or using SAIL recipes. Information that exists outside of
a nested CDT can be used by the Report Builder wizard. SAIL recipes (such as a pie chart drilldown
to a grid) are strongly recommended in order to enhance the effectiveness of your reports.
Sites
Once your Records, Reports, and Processes are established, unite them logically in building a Site.
According to the groups used by your application, consider how many Sites would be appropriate to
build.
Security Summary
With the major aspects of your application complete, select Security Summary from the main menu
in the Appian Designer screen. Modify or add security to any objects you may have missed in
accordance with Appian Documentation recommendations.
7
SECURITY SUMMARY
Each object in Appian requires security to provide the correct user access. This table lists all design
objects and the associated security roles.
Appian Object
Security Details
Applications
●
●
●
Administrator – update security, import
Editor – add/remove objects from an application
Viewer – view properties of an application, export
Rules and
Constants
(inherited
from folder)
●
●
●
●
Administrator – update security, create sub-folders
Editor – make changes to or delete rules/constants, view security
Viewer – view rules and constants and view the folder in the hierarchy
Deny – no privileges
Note: Even if a user is denied access to a rules folder, they will still be able to use rules and
constants in other objects
Data Stores
●
●
●
Administrator – update security, delete, publish
Editor – add entities, save, verify mappings
Viewer – view definition, select via designer, read/write from RDBMS
Note: Any users that query the database must have at least viewer access
Data Type
Knowledge
Centers and
Folders
Feeds
Groups
No security defined for data types. Only System Administrators can delete them.
●
●
●
Administrator – view content, add/delete files and folders, add/remove users
Editor – upload and download files, view user access levels
Viewer – view and download files (cannot upload files)
●
●
Administrator – modify security
Editor – view security, save, edit, and delete feeds
●
Administrator – can define security for the group
Note: Only System Administrators can create users
8
SECURITY SUMMARY
Appian Object
Security Details
Process
Models
●
●
●
●
●
●
Administrator – publish, delete a lock, delete model, change security
Editor – edit, save, view documentation
Manager – override task assignment, add note
Viewer – view the process model, use process model data
Initiator – start the process model
Deny – no privileges
Record Types
●
●
●
●
Administrator – update security, delete
Editor – update properties, view security
Auditor – view security
Viewer – view properties, view in tempo
Note: security can also be defined for related actions, views, and default filters to determine
user access
Reports
●
●
●
●
Administrator – delete, update security
Editor – update properties, view security
Auditor – view the report configuration
Viewer – view in tempo
Sites
●
●
●
●
Administrator – delete, update security
Editor – update properties, view security
Auditor – view the site configuration
Viewer – view as end user
9
STANDARD OBJECT NAMES
We recommend the following naming conventions for Appian objects. Adapt these standards to
your environment as needed.
Appian
Object
Recommended Naming Standard
●
Applications
●
Published applications. These applications contain the navigation items and their
names are used to group together Actions.
○ Use a short descriptive name that is meaningful to the end users.
All other applications. These applications are not published and are commonly used
to promote artifacts between environments.
○ Use a short unique prefix to identify your application such as HRO for an HR
Onboarding application. This prefix is used for naming all objects related to
the application.
○ Use a short descriptive name.
○ Include the type of the application e.g. CDTs and Data Stores or All
Contents.
○ Suffix the name with a version number such as v1.0.
Example: For the first release of an HR Onboarding application, the published application is
named HR Onboarding and the application bundle used to promote the remaining
artifacts is named HRO HR Onboarding All Contents v1.0..
●
Record
Types
●
Use a short descriptive name that is meaningful to the end users. Do not use the
application prefix as record types are designed to be enterprise-wide entities.
For record type views, use a short name that best describes the subset of the record
data that is represented in the view.
Example: For an HR Onboarding application, the onboarding data and milestones are
displayed in the Onboarding view of the enterprise Employee record type.
●
Tempo
Reports
●
●
Use a short descriptive name that is meaningful to the end users. Because a Tempo
Report is composed of several graphical elements (grids and charts) as well as
editable fields used to filter and sort the report data, the Tempo Report name should
not be narrowed down to a specific timeframe or subset of the data.
Do not preface the report name with the application specific prefix.
Do not suffix the report name with Report.
Example: For an HR Onboarding application, the Tempo Report HR Onboarding
Department contains several charts with dynamic filters to show the number of
10
onboarded employees by month and department
STANDARD OBJECT NAMES
●
Actions
Use a short descriptive name that is meaningful to the end users. Actions are
grouped by applications' name using filters so using the application prefix is not
preferred.
Example: For an HR Onboarding application, the HR department has access to the action
Start new employee onboarding within the filter Human Resources.
Custom Data
Types
●
●
●
Provide descriptive names for your custom data types (CDTs).
Preface the name with the application specific prefix.
Use a custom namespace for yours CDT to group them and associate them with a
specific application. Changing the namespace requires editing the XSD for the CDT.
Example: The CDT representing a new employee in an HR Onboarding application is
named HRO_Employee. Its namespace is defined as urn:appian:hro
Changing a CDT namespace results in the creation of a new CDT unrelated to the original
CDT. All references to the original CDT in process models, rules, reports, etc... must be
manually updated to the new CDT.
Variables
●
●
Use camel case for defining variables.
Use the suffix List to indicate that the variable is a multiple.
Examples:
●
●
●
firstName
salaryAdvanceAmount
generalExpenseList
Using camel case helps differentiate words without adding clumsy underscores.
Rules and
Constants
●
●
●
●
Preface the name with the application specific prefix.
Optionally, use an additional prefix to group related rules and constants.
For Constants, use uppercase for all letters.
For Rules, use pascal case.
Examples: In an HR Onboarding application, rules and constants are named as follow:
●
●
●
HRO_ComputeBaseSalary for the business rule that computes the base salary of
an employee.
HRO_IMG_CAREER_HISTORY_ICON for the constant containing the career icon.
HRO_GetEmployeeOnboardingTasksStatus for the query rule that retrieved the
status of the onboarding tasks for an employee.
11
STANDARD OBJECT NAMES
●
Groups
●
●
●
●
If the group is not intended to be seen directly by the end users, preface the name
with the application specific prefix. For example, the administrator group of the
Employee record type is never used by the end users and is named HRO
Employee Record Administrators
If the group is intended to be seen directly by the end users such as a Tempo
audience group, use a short descriptive name.
Create a parent group named for each application.
Name child groups according to their security role.
Each application should include the following child groups at a minimum.
○ Application Administrators
○ Application Users
Examples: An HR Onboarding application has the following groups:
●
●
●
●
●
Process
Models
●
HRO HR Onboarding is the parent group of the application.
HRO Administrators is the group containing the application specific administrator.
HRO All Users is the group containing all users that have access to the HR
Onboarding application.
HRO Human Resources is the group containing the Human Resources employees
that handle task assignments for the HR Onboarding application.
Preface the name of the process model and the process model folder with the
application specific prefix, except for models that will be used as Related Actions
since the model name is used as the related action label.
For running process instances, preface the name with the application specific prefix
and include key data points that help identify the process instances in a Process
Report.
Examples: In an HR Onboarding application, the main process model is named HRO
Onboard New Employee and a running instance of this process model is named HRO
Onboard John Doe - 2014 01 01.
●
Knowledge
Preface the name of the knowledge center and the community with the application
specific prefix.
Centers and
Communitie
s
Examples: In an HR Onboarding application, the application's community is named HRO
Community and each onboarded employee has a dedicated knowledge center named
HRO Employee Name Documents.
12
DOMAIN PREFIXES
Domai Name
n
Details
ac!
Activity Class Parameter
Designer-configured inputs within each node. Used in activities
within a Process Model
pv!
Process Variable
Designer-configured variables. Used anywhere in Process
Models
pp!
Process Property
Default system properties that define information about each
instance (e.g. pp!initiator). Used in Process Models
pm!
Process Model Property
Default system properties that define information about the
model (e.g. pm!version) Used in Process Models
tp!
Task Property
Default system properties that define information about each
activity (e.g. tp!starttime). Used in each activity within a
Process Model
rule!
Rules
References designer-created interfaces, expressions, queries,
decisions, and integrations in any expression in Appian. Allows
keyword syntax.
cons!
Constants
References designer-created Constants in any expression.
fn!
Functions (default prefix)
Call basic functions in any expression. Does not allow keyword
syntax.
ri!
Rule Inputs
Designer-created inputs for all rule types (interfaces,
expressions, queries, decisions, and integrations). Used in any
rule designer.
rf!
Record Field
References all fields available in the record source (i.e. columns
in a database for an entity-backed record). Used in the record
type designer
rp!
Record Property
System defined record properties. Used in the record type
designer.
type!
Type Constructors
Returns a value where the output type is a Custom Data Type.
Used in any expression and allows keyword syntax.
a!
Appian Function
Call certain functions (especially SAIL functions) in any
expression. Allows keyword syntax.
local!
Local Variable
Define or call a variable that can be used in load() or with()
functions. Used in any expression.
fv!
Function Variable
System-defined properties of certain functions (e.g. fv!index).
Used in certain functions and identified in the documentation
of the function.
13