This resource is intended to supplement the 20.

3
Fundamentals Course on the Appian Platform.

DEVELOPER COURSEBOOK
SYLLABUS

WELCOME

The Appian Developer Fundamentals course provides a fundamental understanding of

how to build applications using Appian. This course is designed for those who are
joining a team already actively developing or supporting applications. Ideal roles
include technical support, dev ops, and dev planning.

OBJECTIVES

By the end of this course, you should be able to:

Explain Appian's terminology and relationships between all design objects
Configure all types of Appian design objects
Develop complex business rules
Assemble functional proces smodels
Design dynamic user interfaces
Create basic integrations with web services, databases, or other systems
Test and debug Appian objects
Monitor performance of Appian design objects to prevent potential issues
Interpret and troubleshoot technical issues with Appian design objects

2
COURSE
AGENDA

DAY 1 UNDERSTANDING APPIAN

Tempo | Sites | Application Planning

DAY 2 REUSABILITY IN APPLICATIONS

System Logic | Interfaces | Reusable Components

DAY 3 CREATING WORKFLOWS

Process Modeling | Automation | Saving Data

DAY 4 WORKING WITH DATA

Records | Reports | Related Actions

DAY 5 DEVOPS
Exporting & Importing | Administration Console

CONTINUE YOUR LEARNING

Community | Documentation | Academy Online

3
Understanding Appian

End users can interact with Appian in several ways: Tempo, Sites and
Embedded. When deciding which option to provide your users, you should
think about what applications or objects they will be interacting with. Even with
three different options, most users will use Sites over Tempo and Embedded.
To understand the best option for you, continue reading below.

Tempo Sites
The Tempo interface enables users to Sites are a way to provide users with a
have a complete picture of many customized user experience focused on a
applications in Appian. It is designed specific set of functionality. With Sites,
for knowledge workers who need to users are presented with a business-
access all components of multiple orientated navigation experience that is
applications quickly. Tempo users get inline with what they are used to. Similar
a holistic perspective of past, present, to Tempo, Sites can be branded to match
and future business activities as well the organization identity and give a
as fast access to the tools they need familiar look that carries through the
to get work done. application.

Embedded
Some businesses need more control over site navigation or look and feel. They
may cater to external users and therefore want to have consistent branding
across the application. Or they may be integrating with an existing intranet portal
and want to keep the interface employees are familiar with while introducing
new capabilities. With Embedded Interfaces, companies can embed Appian
objects into their web page or portal.

4
Understanding Appian

Planning is an important first step as you begin your Appian build. During the
planning phase, your goal is understanding the purpose of the application, the
needs of your users, and how you want to handle data. Here are some key
steps.

Users/Groups - Users are individuals who use or are affected by

your application. We utilize groups to manage security,
messaging, and tasking for those users. All users should be
placed in a group. Groups may mirror your organizational
structure, or be functional based on specific objects or actions.

Records - Appian Records are a new type of record that allow

you to see your business information from a number of
different perspectives, and take action in the context of that
information. Think of them as collection points for everything
you care about regarding a specific item.

Item 1
Reports - Graphs display aggregated data from multiple sources
Item 2
into a single view to aid in organizational decisions. Reports
Item 3
includes Pie Charts, Line Charts, Bar/Column Charts and Grids.
Users should be able to Filter, Drill-down and click on Links that
dive deeper into the data to give users more information.
Item 4

0 10 20 30 40

Data Points - What is that you want to know? Data Design is

crucial to the performance and scalability of any application. As
you plan your records and reports, consider all of the supporting
data points you need to collect in order to create them.

5
Understanding Appian

Process Models - Business Process Model Notation (BPMN) is

the standard by which anyone can graphically describe their
business processes. Appian automatically translates your business
workflows to executable processes. Create a High-Level Diagram
using Start/End Nodes (CIRCLE), User/System Activities
(SQUARE) and Decisions (DIAMOND).

Collaboration - News Posts, Notifications and Emails are an

important way to communicate with individuals inside and
outside of your organization. Understanding what messages
should be shared, when they should be shared, and who they
should be shared with are important topics to think about.

SUMMARY

Many of our students are tempted to shortchange the planning process in favor
of getting into the tools and building as soon as possible. We caution you
against this approach.

The more time you provide yourself to plan and think through the data and
processes you plan to work with, the faster your development efforts will
proceed.
Work closely with your
product owners,
stakeholders, and business
analysts to make sure you
properly prioritize the
features functions of your
application.

6
Application Structure

APPLICATIONS ARE CONTAINERS

An application is a collection of objects that represent a business solution.

Applications functionally group design objects together to form the user
interfaces, logic, processes, and data your users interact with while doing work
in Appian. This container can also be shared or moved from one environment to
another.

Objects are bits of self-contained logic that may be referenced and reused from
within 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 your application (which itself is a type of object).

This diagram illustrates the objects found in an application container.

7
 Magnifying glasses are
Object Management links to documentation

Groups
Users within Appian are managed through the use of Groups. Groups allow
developers to designate what users can SEE and DO certain application objects
through the use of Object Security as you build, create, and develop components.

There are 2 schools of thought when creating Groups: System vs User Groups.

System Groups User Groups

When accessing different Applications revolve around a
tools within the Appian business solution (a CRM app for
platform, your access instance) therefore have various
depends on what System Departments & Roles within that
Groups you are a member of. business solution that serve
This includes Designers, different purposes. Designating
Process Model Creators, these different Role-Based
Tempo Users, and more. Groups allows you to designate
what end-users can access.
Object Folders
Folders allow developers to store and organize design
objects in a content management system for both security
and organization purposes. When creating and designing
how you want to manage your objects, this depends on the
structure of your team and your business.
From time-to-time you might consider creating a layered system of folders and
sub-folders so you can organize your design objects in a more granular focused
sense.

As objects are created and placed in their appropriate folder, they will
automatically inherit the security of the folder unless designated otherwise.

There are 4 primary types of Folders in Appian each used for different
purposes:

Rule Folder I Document Folder I Knowledge Center I Process Model Folder

8
 Magnifying glasses are
Reusability in Appian links to documentation

Custom Data Type

A Custom Data Type (CDT) is a user-defined data structure for logical grouping
related data. For example, when building an application for managing a vehicle
fleet, a CDT for a vehicle might include information such as make, model,
category, year, mileage, and other useful information.

The structure of a CDT appears similar to a table in a

RDBMS. In fact, CDTs can be used to generate new
tables in a database. Conversely, a CDT can also be
created from the structure of an existing table.
However, CDTs themselves are not database tables.
They only share a similar structure and can be mapped
with tables.
CDTs store primitive data (text, dates, numbers, booleans, etc.) When needed,
CDTs can also establish relationships to other CDTs. This is called “Nesting.”

Constants
Constants are developer-configured values that can be used throughout your
applications. They are useful because they provide consistency across many
application objects. For example, if all tasks should send a reminder email after
24 hours of inactivity, the value “24” can be saved and reused in each task within
the application.

There are typically three types of constants:

Business value - This could use any single primitive data type, such as a
maximum order threshold, tax rate, or other commonly used relatively static
value
List of Values - Often used for values used in a selection list like Status or
Category
Reference to an Appian Object - Useful to tunnel to a folder, group,
document, etc.

8
Reusability in Appian

Expression Rules
Expression rules are reusable, designer-configured functions
used to manipulate data. They can have a combination of
literal values, operators, variable data, functions, and other
rules and constants.

"New Ticket " & ri!ticketId & " by " & user(ri!username, "firstName")
New Ticket AN-1097 by John
Literal values include text values, integers, decimals, and special literals such as
true, false, and null. In the image above, “New Ticket” and “by” are literal values
that return text. Make sure to use quotations when referencing literal text values
in an expression

Operators used by Appian expressions include arithmetic operators like addition

and subtraction and comparison operators like less than or equal to. For a full list
of operators, check the product documentation. In the example above, the
ampersands (&) are an operator that serves to concatenate portions of the
expression.

To call variable data in an expression, create a rule input and define the data
type. Call the variable data rule input in your expression by using the ri! domain.
To test the expression, enter test values in the Test Inputs View. In the example
above, ticketId and username are inputs for this expression. It’s also possible to
use other domains depending on where the expression is used. For a list of all
domains, view the Domain Prefixes section.

Appian expressions can use all sorts of system-defined functions such as

conversion functions, date and time functions, and logic functions. For a full list
of functions available in Appian, consult the product documentation. In the
example above, the expression is calling the user function to retrieve the first
name for the username input.

9
Reusability in Appian

Decisions
A Decision is a grouping of business rules that determines
output values based on a set of inputs. Unlike expression
rules, which primarily calculate or manipulate data, Decisions
are best used to encapsulate complex, business-specific logic.
Decisions are configured in the decision designer, which
enables fast, intuitive implementation of business logic
without using expressions by way of decision tables.
Decisions can be called from any expression using rule!, so they can be reused
across multiple objects throughout the system.
For inputs, decision tables can accept text, numbers, dates, and booleans. The
possible outputs for decisions include booleans, dates, documents, folders,
groups, numbers, process models, text, and users.

Interfaces

An interface returns one or more components to display on

a record view, Tempo report, or form. This is the primary
object that developers use to display and retrieve
information from application users. Interfaces are defined
using expressions, which enable dynamic behavior and reuse
of common logic and components across multiple objects
throughout the system. They are called and evaluated in the
same way as expression rules or query rules.
The Appian interface designer is similar to the expression rule designer. It
includes a design pane on the left, where developers will select and edit
components, a test pane in the center that shows a live version of the interface
as it is being built, and a data pane on the right showing the variable inputs used
in the form. These interface inputs are functionally similar to rule inputs (ri!),
and are called the same way within the form.

10
Creating Workflows

Process Models
Process Models allow Developers to create executable
workflows through a drag-and-drop interface. Process Models
drive Actions and Related Actions in Appian and are made up
of nodes representing each of the activities within a workflow.
Each workflow is made up of activities performed by a user or
the system to complete the process. The three shapes you’ll
generally see in Process Models are rectangles (activities),
diamonds (decisions), and circles (start/end).

Once you create a new process model, set basic process properties. The
Properties window governs all of the properties for the process model and has
important settings for variables, alerts, and data management. While not part of
the properties tab, you should also set security on a process model as it’s
created. For example, you’ll want to set Administrators so your admin group has
access to everything within the process model.

Application Actions
Once you create a Process Model, an Action is required to expose the process
to users in Tempo. Then, users can trigger the process through the Actions tab.
If a Start Form is configured for the process, users can complete the form prior
to starting the process.

Actions will only show in Tempo if the security is defined correctly. To view an
Action, users must be granted at least View privileges on the application and
Initiator privileges on the Process Model.

11
Creating Workflows

Start Forms
To account for tasks that are regularly abandoned, Developers can configure a
Start Form to display to a user when first selecting an Action. The process
instance won’t actually begin until the start form is submitted, thus limiting the
number of abandoned processes. Start forms are also required when using
sites, as the start form is always displayed in the site tab.

User Input Tasks

User Input Tasks allow Developers to collect information from users in a
process. While a Start Form displays a form at the beginning of a process, a
User Input Task can be used at any point to send a form to users. When a User
Input Task is triggered, users who are assigned the task will receive a
notification through email or a mobile push. They can complete the task directly
from the Tasks Tab in Tempo or a task link.

There are a few required fields that must be configured in a

User Input Task:
Task Name - The name that displays in the Tasks tab or a
Task Link
Inputs - Any data that is collected from the form and saved
to the process
Form - The interface referenced within this task
Assignment - The users or groups who must complete this
task

Any node input that is created for a User Input Task is known as an Activity
Class Parameter, which uses the prefix ac! in expressions. Activity class
parameters are required if collecting information that a user enters on the form.

12
Creating Workflows

Data Stores
Data stores connect Appian to external relational databases in order to store
and retrieve application data. Learn how to create data stores, run DDL scripts
and retrieve external data in your application.

Data stores allow you to insert, update, query, and delete data in the format
needed by your applications without writing structured queries (SQL). You must
have a business data source configured to use this feature.

Write to Data Store Entity

The Write to Data Store Entity Smart Service adds process data to an entity in a
Data Store. It allows you to select a single entity in a data store to save or
update data.

You must create a node input with the same custom data type (CDT) as the
entity in the data store that you select. The way you define your custom data
type determines whether you can update existing records in the data store. You
must also designate a field in the CDT as your record ID (primary key) and
specify an existing value, or the data written is always inserted as a new record.

Custom Data SQL

Type Data Store Database

13
Working with Data

Records
Records are a visual representation of a collection of
business data on something that has importance to an
organization. They are designed to merge information for
users so that they can make better and more effective
decisions. Records can draw data from three sources:
datastore entities (Entity-Backed), process models (Process-
Backed), and external services (Expression-Backed).
Entity-Backed records are derived from a datastore entity, which is a table in
a relational database. One record represents one row of that table. When
constructing a record, you will have access to all fields within that row.

Process-Backed records draw information from an instance of a running

process or recently completed (but unarchived) process. The record will have
access to the current values of all process variables within that instance, as
well as process and process model properties (pp!).

Expression-Backed records are less defined. Since they are built using an
expression rule, whatever one record represents will depend on the source
of the data and how it has been brought brought into Appian. Often,
Expression-Backed records use an integration as the source of the data.

Referencing Data Within Records

When constructing a record OR referencing a record using recordtype! in

another inferface, you can reference specific fields using rv!. The Record
Variable prefix tells Appian that you are looking to reference a field within a
specific record. This allows Appian to know exactly what value its working with
BEFORE run-time. If you want to reference a specific field, your syntax would
be rv!record[recordtype!###Your Record Name###].fields.###fieldName###.
You can also simply type rv!record[###fieldName###] and Appian will
autosuggest the appropriate field which will autofill the rest of the syntax.

14
Working with Data

Queries
Queries allow Developers to return data from a relational database and reuse
meaningful data throughout Appian. Queries are configured in expression rules
using the Visual Query Editor. With 20.3, if a Record Type already has the
needed information, you can simply use the new rv! and recordtype! syntax to
query a record versus building a new query.

There are four parts that must be configured as part of a query:

Source - Defines where the data will be queried from and requires a constant
that references a Data Store Entity
Paging and Sorting - Determines how many rows to return and how to sort the
data
Filters - Conditions for which data to return in the result set
Fields - Columns to return from the data source

Reports
Reports are an aggregation of data from multiple sources displayed in a single
dashboard. The data can come from processes, process analytics, relational
databases, web services, and integrations. To build a report, you must first build
an interface to display in the report.
The most common objects to display in reports are grids and
charts.

Grids can be used to display tabular data. Each grid can use
its own source, and can be configured to include text, links,
images, and more. Grids are interactive too, so you can
browse between multiple pages and sort columns in the
grid if necessary.

Charts display data aggregated using a function such as

sum, count, or average. They are useful to display trends or
outliers within your data and provide visual appeal. Appian
uses four kinds of charts: Line, Bar, Column, and Pie.

15
Integrations

When thinking about connecting with third-party systems, it helps to frame it

with the question, Which system is initiating the call? If a third party-system is
making the request, developers would create object to return a response to the
system. Similarly, if Appian is making the request, a different set of objects
would be configured to connect with the other system.

Integrations & Connected Systems

Integrations and connected systems work together to let developers quickly
connect to an external system. Connected systems contain particular common
integration information like endpoint and authentications. This enables you to
generate multiple integrations from the same connected system. Once built,
Integrations can be called in an expression rule, interface, or process model.

Web API's
Web APIs provide a way to expose Appian data and services to outside
systems. Each Web API is an association between a URL/HTTP method
combination and an expression. When a client makes an HTTP request to the
given URL, the associated expression is executed and the result is returned to
the client. This means that any data or service that is available inside an
expression can be exposed to an external system via a Web API.

Web API's
Systems Calling Appian

Appian Calling Systems

Integrations

16
DEVOPS

Application Deployment
Typical development in Appian requires three environments: Development,
Test, and Production.

Development Environment
Used to design applications. Usually only developers have access to this
environment, and it provides access to create all application objects.
Test Environment
Used to ensure the application meets all requirements and behaves as
expected. All applications should be fully tested before end users are granted
access. Types of testing include unit testing, user acceptance testing,
integration testing, performance testing, and more.
Production Environment
Used for all end user access. Only applications that have passed all testing
should be promoted to Production.

In order to deploy applications or objects from one environment to another, the

appropriate components must be exported and imported. It is possible to import
either the entire application or export only certain objects using a patch.

Security Summary
This feature provides an overview of all objects and the security role associated
with each object.
Missing Precedents
This feature Lists any required supporting objects that do not exist in the
application.

Development Staging/Test Production

17
Agile Development

This course does not teach Appian's delivery philosophy, but it is important to
note that Appian recommends and uses an Agile delivery methodology as it is
the best way to ensure speedy delivery of value. Agile is an umbrella term
describing a growing list of methodologies supporting the 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.

The goal of each work increment, also

known as a “sprint,” is delivering a
finished product, even if minimally
capable.

Developers prioritize work in a backlog, and organize the backlog by highest

value first. Planners score each item in the backlog with a relative difficulty
rating, a process called “sizing.” This helps developers choose which items to
accomplish from the backlog in each sprint

It is important to remember that the goal of each sprint delivering 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. Once a feature, or "story," is delivered, any future
improvements go on the backlog and get re-prioritized.

18
Application Checklist

This checklist serves as a notional path a Developer may take when building an
application. There are numerous ways to effectively build applications, but the
way outlined below follows the sequence used in class with corresponding
helpful links.

Log Into Appian Designer

Click on New Application

In the Name field, type the name of your application

In the Description field, add a short description

Click Create ---> Set Security > Gear > Application Security

Folder Creation
Folders allow Developers to organize and assign access rights to the
application objects you create. Specific Folders are needed for Rules
(Constants, Decisions,Integrations), Documents and Process Models.
Documents or rules contained in a folder can automatically inherit user-
rights from the folder (Process Model folders do not provide security
inheritance).

Document Management
If your application requires file uploads or documents, create your
Knowledge Center.

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.

19
Application Checklist

Group Creation
Within 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 and set the Administrators group as the
role of Administrators for the All Users group.

Additional Objects

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 you will need.

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.

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.

Create your Data Store Object. Once created, click Add Entity to connect your
CDT to the Data Store. Click Verify and Save and Publish.

In your process model, add a Write to Data Store Entity node and configure it to
match your newly created Data Store.

20
Application Checklist

Thoroughly debug (File > Start Process for Debugging) your process model to
ensure all data is effectively captured from the interface and successfully stored
in your Data Store via Cloud Database (Navigation Icon > Cloud Database)

With your Data Store structure in place, create your Queries. Generally it is good
to have a query to retrieve all the items and another to retrieve a single item by
ID.

Filter By Data Store Returns

firstName
customerId OR
firstName
lastName
email
Entity-Backed Record
Create a new Record Type. Set appropriate security.

Identify the source of your Data.

Set your Default Filters and User Filters.

Select Edit 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 > 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.

21
Application Checklist

Reports
The way your data is structured determines 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 Interface Patterns (found on Appian Documentation).

Information existing outside of a nested CDT can be used by

the Report Builder wizard. Interface Patterns, 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.

22
Standard Object Names

Object Naming
While Appian does not enforce any particular naming convention, it is helpful
for development teams to agree on a consistent method of naming objects
based on their type. This makes it much easier to locate and sort through
objects using pickers and type ahead fields. Below you will find suggested
examples of naming conventions used by the Appian training team.

Actions
Use a short descriptive name that is meaningful to the end users.
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). Prefix the name with the application specific
prefix. Use a custom namespace for your CDT to group
them and associate them with a specific application.

Example: The CDT representing a new employee in an

HR Onboarding application is named HRO_Employee.
Its namespace is defined as urn:appian:hro

Variables
Use camel case for defining variables. Using camel case helps differentiate
words without adding clumsy underscores. Use the suffix List to indicate that
the variable is a multiple.
Examples: firstName or categoryList

23
Standard Object Names

Rules and Constants

Prefix 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:
Business Rule > HRO_ComputeBaseSalary
Constant > HRO_IMG_CAREER_HISTORY_ICON
Query Rule > HRO_GetEmployeeOnboardingTasksStatus

Knowledge Centers and Communities

Prefix the name of the knowledge center and the application specific prefix.

Examples: In an HR Onboarding application, the application's community is

named HRO Community and each on-boarded employee has a dedicated
knowledge center named HRO Employee Name Documents.

Process Models
Prefix the name of the process model and the process model
folder with the application specific prefix. For running process
instances, prefix 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 - 2020 01 01.

24
Standard Object Names

Groups
If the group is not intended to be seen directly by the end
users, prefix 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.

Examples:
Parent Group > HRO HR Onboarding
Admin Group > HRO Administrators
All Users Group > HRO All Users

Organization vs Function
When creating groups, consider creating groups that are for organizational and
functional purposes. Depending on the size or your team, you may want to
create a group specifically for those who will be editing process models or
another specific type of object/component.

Organizational Groups Functional Groups

Environment-Wide Application Specific

HRO HR Onboarding Team HRO Process Model Editors

HRO HQ Executives HRO Record Type Editors
HRO Finance Team HRO Record Type Viewers
HRO Healthcare Division HRO Report Viewers

25
Domain Prefixes

Data Domains
There many areas in Appian where you can call upon stored data, functions,
and user-created reusable objects. To reference these items, you must use a
prefix to identify where Appian should look. This is a list of prefixes you can
use to find and utilize these components.

Activity Class Parameter

ac! Optional variables to use in specific situations. Used in activity
objects within a Process Model.

Process Variable
pv!
Developer-configured variables. Stores information and can be
referenced throughout the process model.

Process Property
pp! Default system properties that define information about each
instance (e.g. pp!initiator). Used in Process Models.

Process Model Property

pm! Default system properties that define information about the model
(e.g. pm!version) Used in Process Models.

Task Property
Default system properties that define information about each
tp!
activity (e.g. tp!starttime). Used in each activity within a Process
Model.

Rules
References developer-created interfaces, expressions, queries,
rule!
decisions, and integrations in any expression in Appian. Allows
keyword syntax.

Constants
cons!
References developer-created Constants in any expression.

26
Domain Prefixes

Functions
fn! Call basic functions in any expression. Does not allow keyword
syntax.

Rule Inputs
ri! Developer-created inputs for all rule types (interfaces, expressions,
queries, decisions, and integrations). Used in any rule designer.

Record Variable
rv! 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.
recordtype!
References a specific Record Type. Can be used to create a Record
View on an Interface.
Type Constructors
type! Returns a value where the output type is a Custom Data Type. Used
in any expression and allows keyword syntax.

Appian Function
a! Call certain functions (especially SAIL functions) in any expression.
Allows keyword syntax.

Local Variable
local! Define or call a variable that can be used in a!LocalVariables()
function. Used in any expression.

Function Variable
fv! System-defined properties of certain functions (e.g. fv!index). Used
in certain functions and identified in the documentation of the
fn! function.

27
 Click the magnifying glass
Additional Resources for all available resources

Enjoyed your training experience? Sign up for another course taking

place at one of our Global Headquarters.

Academy (Classroom & Onsite)

Want to book your next course? You can request an onsite training at your
organization or you can sign up for any of our public courses in our US, UK and
Australia offices.

Academy Online
For users looking for a self-paced learning experience or for users who wish to
continue their education beyond the classroom, Appian provides free, online
training and exercises at Academy Online.

Documentation
Learn more with instruction, guidance, reference, and a plethora of examples and
recipes to suit almost any situation. You can find them at docs.appian.com

Community
The Appian Community acts as an information hub for Appian's supporting
resources as well as providing a valuable one of its own: Discussion Forums.

Playbook
Created and maintained by expert practitioners in our Professional Services
department, The Appian Playbook offers checklists, tools, techniques, examples,
and best practices for managing project delivery.

Credentials
Put your knowledge to the test by becoming Appian Certified. Level 1, 2, and 3
certifications can be attained through Academy and will be recorded as part of
your Appian skill set.

28