Article

Analyzing Performance Issues

joel.larin — Thu, 11 Jun 2026 21:49:04 GMT

Current Revision posted to Article by joel.larin on 6/11/2026 9:49:04 PM

While using the system, users may encounter slowness and performance issues. The root causes of these issues vary based on usage patterns, application design, system resources, and external factors.

For the purposes of this guide, “slowness” is defined as an aspect of the application or platform not responding within an expected, defined range. For example:

As an end user, page loads take longer than pre-defined SLAs or seems slow
As a designer, Health Check or logs indicate a response time above the defined threshold

This guide is designed to help teams methodically investigate reported issues and identify root cause(s) by performing the following steps:

Document Issues
Triage Issues
Analyze Issues

Document Issues

Your team needs detailed information about the performance issues in order to start the analysis process. A simple email stating that “the system is slow” is not actionable. In order to collect this information, your team must first provide guidance to end users on how to document performance issues. You may also need to train your support staff on how to collect this information. This ensures that the responding team has a sufficient level of information to quickly triage and analyze an issue.

The following list provides the minimum data points that should be collected by your support team or by the end users themselves when they experience a performance issue:

Name of the user reporting the issue
Username of user experiencing the issue
URL of the Appian environment
Date and time of issue
User's environment (e.g. browser type and version, use of VPN/virtual desktop)
Steps to reproduce the observed behavior, noting specific screens and/or record/reference IDs related to latency
If the issue is experienced in a browser, recording of the network logs captured using the browser’s Developer Tools could be useful. See “How to generate a browser network capture (HAR) file” for more information

Encourage the person documenting the issue to be as detailed as possible: What is slow? How slow? What data did you enter?

Sample Issue Report

Reporter	John Smith
Username	john.smith
Site URL	https://myapplication.domain.com/suite/sites/mysite
Time of issue	Between 10:00am and 10:30am EST
Environment	Windows 10, IE Edge - over VPN
Issue Summary / Reproduction Steps	I logged in as john.smith and executed the Create Record action from the Finance site. I filled out the "Enter Basic Information" screen with my name and address, and added 10 locations. I clicked Submit, and the system took approximately 30 seconds before displaying the second form ("Enter Additional Details"). I expected the second form to appear within 5 seconds.

Type:
Value:

Triage Issues

Performance issues can occur anywhere in an application so the first thing to do is to triage and categorize the reported issues. Looking at the environment metrics in My Appian is a great place to start to determine if performance could be impacting the wider the platform.

First, confirm the validity of the usage patterns triggering the reported issue(s). Invalid usage might best be resolved through training or application guardrails rather than in-depth performance analysis and tuning.

Some example questions to help you decide this are:

Do users have realistic expectations?
- Is the user seeing SLA violations for response times?
- Is the reported issue tied to an area of the application that is expected to run longer, such as a large report?
Are users utilizing the system as intended? Can users do something they shouldn’t be able to do?
- Exporting millions of records, or processing extremely large file upload might not be expected or valid.
If performance testing, is the test realistic?
- Poorly designed tests (i.e. higher than expected volume) may result in performance issues.
- See the Performance Testing Methodology for guidance on test creation and validation.

Analyze Issues

Initial Analysis

Once you've confirmed your application is not performing as expected, your first goal should be to isolate the problem to a specific area of your platform. Start by following the tree below. Once you have reached an endpoint, navigate to the appropriate section below for more information. Restart the decision tree as analysis dictates.

Detailed Analysis

Network/VPN

If all web interactions are slow, including those not associated with Appian, then your issue is likely related to your network connection or specific computer rather than the platform. Check these things first to confirm:

Key Questions

Potential Issues

Next Steps

Relevant Logs And Tools

Are you on VPN/Citrix, etc.?

Latency is sometimes introduced by intermediate web proxies like VPN or Citrix

Diagnose
- Check with peers to see if there is latency on direct network access
Action
- Engage IT/Network support team

Network logs

Are your peers experiencing similar latency?

Issues may be isolated to your machine or region

Diagnose
- Verify if issues are specific to your location (i.e. floor, office, network connection)
Action
- Try different connection
- Engage IT/Network support team

Network logs

Web Layer

If your web layer interactions are slow:

Key Questions	Potential Issues	Next Steps	Relevant Logs And Tools
Are nodes load balancing as expected?	Load is imbalanced or otherwise not functioning correctly	Review load balancing mechanism (mod_jk, F5 device, etc.). Verify network traffic is being routed properly	Web server error logs Load balancer logs/configuration
Is the Web Server performing as expected?	Threads may be stuck, or CPU utilization may be too high for resources available	Isolate which threads/requests are causing issues	Web server access logs Web server error logs
Is granular debugging enabled?	Some debugging levels introduce unexpected latency into Web requests	Disable any extraneous debugging	Web server access logs Web server error logs Web-to-App server connector logs (ISAPI, mod_jk/mod_proxy)

App Server

Key Questions	Potential Issues	Next Steps	Relevant Logs And Tools
Is there high CPU utilization/load average?	Application server resources are overloaded	Diagnose Look into logs for high volume requests Run thread/heap dumps Review if application follows best practices or is using more resources than expected Action Optimize application to align with best practices Typical Performance Issues Database Performance Consider scaling resources if needed (i.e. add additional CPU)	Appian system.csv
Is there high heap/garbage collection time?	Application components are using a high amount of memory. Typically seen generating documents or working with very large data sets	Diagnose Look at logs for risks Action Run thread/heap dumps Consider scaling resources if needed (i.e. add additional memory) Consider adjusting Heap settings	Appian system.csv

RDBMS

If your RDBMS interactions are slow:

Key Questions	Potential Issues	Next Steps	Relevant Logs And Tools
Are your queries designed efficiently?	Queries are under/over indexed	Diagnose Run explain plan Analyze Logs Run profiler Review index statistics Action Review the Database Performance play Update indices Redesign queries	DB Slow query logs Explain plan Appian data_store.csv expression.csv smart_service*.csv perf_monitor_rdbms.csv
Are your queries running with the expected parameters?	Indexes are not being applied correctly due to unexpected where conditions or casting to unexpected types	Diagnose Run explain plan Run profiler Review index statistics Action Update indices Update application	DB Explain plan Profiler Appian perf_monitor_rdbms.csv
Is the database tuned to support volume and type of queries?	Database resources are insufficient; settings, such as buffer/cache are overwhelmed	Diagnose Monitor system resources (CPU, Disk Usage, Memory) Action Adjust settings as needed	DB System metrics Appian perf_monitor_rdbms.csv

Engines

Key Questions	Potential Issues	Next Steps	Relevant Logs And Tools
Are all engines up?	Some engines are not accessible, resulting in some requests failing or bottlenecking on limited resources	Diagnose Execute the Check Engine script and confirm all services are available Action Resolve any issues and restart any unavailable services	Appian Diagnostics scripts engine status logs engine.csv perf_monitor.csv
Are your requests load balanced?	Some execution services are being under- or over- utilized due to process design patterns	Diagnose Execute an All Process reports, and count number of processes per engine Action Review process models for instances of MNI or high number of subprocesses Update to use the Start Process service where possible, or minimize use of MNI	Appian Analytics reports Diagnostics scripts engine.csv top_models.csv top_process*.csv
Are engines overloaded?	Engines are overloaded due to high utilization (either throughput or sub-optimal design)	Diagnose Review engine performance logs for extremely low Idle time % (<20%) and Work Queue Size increasing Identify expensive processes Action Decrease utilization by optimizing expensive processes Consider scaling engines if needed	Appian Analytics reports Diagnostics scripts engine_system.csv perf_monitor.csv top_models.csv top_process*.csv

Interfaces/Expressions

If your interfaces are slow:

Key Questions	Potential Issues	Next Steps	Relevant Logs And Tools
Do your interfaces rely on external services or complex database queries?	The service isn't performant or is not functioning correctly	Diagnose Review the interface to look for integration calls (e.g. Integration objects, fn!webservicequery(), a!queryEntity()) Leverage the Performance View and logs to determine if integration calls significantly contribute to overall render time Action If integration based, review the Integrations and RDBMS sections of this guide If not, review the remaining questions in this section	Appian Performance view Application server logs expression.csv data_store.csv
Are your interfaces complicated, or call many expressions?	The time to complete numerous tasks causes the overall interface to perform slowly	Diagnose Review the Performance View to isolate redundant, high volume or poor performing sections of the interface Action Review the Interface Performance And Debugging and Database Performance plays Improve the design of the identified area Consider simplifying the interface if possible, looking for opportunities to do some of the work on other screens	Appian Performance View Application server logs expression.csv data_store.csv

Integrations

If your external integrations are slow:

Key Questions	Potential Issues	Next Steps	Relevant Logs And Tools
Is there an issue in the service?	The service isn't performant or is not functioning correctly	Diagnose Isolate performance using debugging tools to replicate transactions outside of Appian Action If test tools show issues as well, engage owner of service If test tools to not show issues, investigate Appian logs further	External Tools Fiddler, SoapUI, Postman Appian Application server logs expression.csv smart_service.csv integration*.csv HTTP Request/Response Logs
Is there any issue with connectivity to the service?	The network connection to the service is misconfigured	Diagnose Isolate performance using debugging tools to replicate transactions outside of Appian Action Engage IT/Network support team	Network logs External Tools Fiddler, SoapUI, Postman Appian Application server logs expression.csv smart_service.csv integration*.csv HTTP Request/Response Logs

Smart Services

If your smart service execution is slow:

Key Questions	Potential Issues	Next Steps	Relevant Logs And Tools
If a plugin, is the smart service code optimized?	Plug-in code might not be optimized for the parameters provided	Diagnose Debug code using logging or remote tools to isolate poor performing modules. Ensure the plug-in has been written to follow best practices. Action Update implementation	Appian Application server logs expression.csv smart_service.csv External Tools Remote or local debugging with IDEs

Tags: checklists, Performance, Architecture

Machine Learning Overview

joel.larin — Thu, 11 Jun 2026 21:48:36 GMT

Current Revision posted to Article by joel.larin on 6/11/2026 9:48:36 PM

Appian is integration agnostic and has the ability to connect with any machine learning offering that exposes itself with a web API. The purpose of this article is to provide information that will empower your general understanding of machine learning technology regardless of the specific tool being used. Refer to the article for Amazon machine learning integrations that have been written about in detail in Appian's documentation.

What is Machine Learning?

Machine learning is a type of artificial intelligence that uses mathematical models to generate probabilistic predictions by finding patterns in historical data. Machine learning is a subset of AI that focuses on the development of algorithms and models that enable computers to learn and make decisions based on data. The models can be thought of as black boxes that are created by processing many observations both supervised and semi-supervised. These machine learning models are then able to take in one or many observations without a known outcome and produce possible outcomes based on their probabilities.

There are many different use cases and applications for machine learning. This article mainly focuses on machine learning technology that analyzes structured data, such as rows of an Excel spreadsheet or an Appian CDT, and delivers a prediction for a specific field or column in the data. The feature, value, or attribute that is being predicted for is often referred to as the target. Within the context of Appian, we’ll dive into the practical implementation of AI features that integrate with applications.

Other uses for machine learning include natural language analysis and translation and the ability to decipher image contents, done using tools such as IBM's Watson and Google AI respectively.

Appian ML/AI Capabilities

Appian AI Skills facilitate the integration of machine learning and AI capabilities into your application. This is done using a variety of low-code design objects, functions and smart services. Features available within Appian AI Skills include document and email classification with custom-built models, and document extraction with pre-trained models.

Classification models can be custom-built, including being trained and tested using data that will accurately reflect your use case. The Document Extraction AI skill identifies data from PDF documents, extracting and saving data into key-value pairs that can be used within the application or saved within a database.

Appian AI Skills offer pre-trained models that use built-in documentation extraction capabilities.

Pre-trained models in Appian are designed for general use cases and are used in documents that have similar information and labeled values (e.g. structured or semi-structured documents). Incorporating Google AI functionalities into your Appian application enables the integration of various features, including but not limited to natural language processing, translation services, cloud-based storage, and more. See Using Google AI Services for a full list of features available.

Note that starting from January 23, 2024, Appian is no longer selling Appian-provisioned Google credentials to customers. Customers have to purchase the license directly through Google and add their Google credentials to their Appian Admin console.

Appian AI Copilot is a starting point to further AI capabilities using Appian. AI Copilot utilizes generative AI to create functional interfaces by generating an initial interface from the fields in your form through a simple pdf upload. AI Copilot is integrated with Azure OpenAI to enable this functionally in your application. Azure OpenAI leverages generative AI models (e.g. gpt-3, codex, dall-e, chatgpt) to provide writing assistance, content generation, etc. You can use AI Copilot to build interfaces directly from a pdf, resulting in a personalized product that can be further customized according to your specific requirements once the initial interface is generated.

Machine learning, particularly deep learning, is one of the fundamental components of generative AI. Similarly to other machine learning models, generative AI models undergo training with large amounts of data that aids in identifying inherent patterns. The generative AI model is fine-tuned and enhanced with the introduction of more data over time. Leveraging AI with Appian allows you to automate repetitive tasks and simplify processes, streamlining development and increasing efficiency and productivity.

Common Model Types

There are two major categories of model types that are used for making machine learning predictions on structured data:

Regression: predicts a numeric value.
Classification: predicts a categorical value from a discrete, fixed number of possible categories. Classification models can be further broken down into two types:
1. Binary classification: the model has only two prediction values to choose from (ex. true and false).
2. Multiclassification: the model has more than two prediction values to choose from.

Which type you utilize is dependent on the target attribute you want to predict for and your overall objective in creating the model. Read the sections below to learn more about the purpose of each model type and see examples describing appropriate uses of each one.

Regression

Regression models make predictions along a continuous range of numerical values. They have many important use cases (examples below), but can't be used in cases where binary, categorical, or non-numeric values are required without additional processing to the model’s output.
The main metric used to determine accuracy of a regression model is the root mean square error (RMSE). The RMSE represents the standard deviation between predicted and actual values; thus a good RMSE is relative to the range of values you are trying to predict. A perfect model would have a RMSE of 0.
When using a regression model, be aware that the predicted value may not fall within the range of values provided in training data and might take on any positive or negative number. It is important to have a plan for how to address any values that would fall outside of acceptable ranges for your application.

Regression models can be used to predict:

The sale price of a home, given information about the home's size, number of bedrooms, zip code, etc.
The appropriate salary for a job posting, given information about that job's difficulty and expected characteristics of qualified candidates.
The number of viewers who will watch the premiere of a new TV series, given information about the show's genre and cast.

Binary Classification

Binary classification models predict for a value that has only two possible outcomes.
A binary classification model will return a value (true or false) and a predicted score (a number between 0 to 1). By default if a predicted score is greater than 0.5, then the predicted value will be true. However, machine learning tools typically allow you to adjust the score threshold to alter the number of true and false values depending on your use case.
The main metric used to evaluate performance of a binary classification model is Area Under the Curve (AUC). The AUC is represented as a number between 0 and 1. A number closer 1 indicates a highly accurate model. Values near 0.5 represent the model is no better than guessing at random. Values close to 0 indicate the model has learned correct patterns, but is using them to make inverse predictions.

Binary classification models can be used to predict:

Whether a job candidate should be given an offer of employment, given information about their qualifications and interview scores.
Whether a loan application should be approved or rejected, given credit details about the applicant.
Whether someone will sign up for a service, given their demographics.
Whether a bank transaction is fraudulent, given information about how much that transaction deviates from the account's typical usage patterns.

Multiclassification

Multiclass models predict for a categorical value from a list of three or more discrete, finite possibilities.
A multiclass model will return a list of values and their related probabilities. The value with the highest probability represents the model's best prediction. For example, if you are trying to predict which tier of support a customer service case should be routed to, a multiclass model might return: Tier 1 - 60%, Tier 2 - 13%, Tier 3 - 27%.
Since the target attribute's possible values are derived from training data, the model will never deliver a prediction value that did not occur in the training data.
The main metric used to determine the accuracy of a multiclass model is called an F1 score. The F1 score is the harmonic mean between precision and recall. The range is 0 to 1. The closer the value is to 1, the better the model.
Some machine learning tools set a limit on the number of possible predictable values that a multiclass model can have. This is because target attributes with hundreds or thousands of potential values can be difficult to train and have a higher likelihood of failure and poor model performance.
To make predictions from a group of possibilities that is larger than a machine learning tool's limit, consider using a series of different models. For example, to classify animal species from an image, better results can be achieved by first training the model for a more general classification (e.g. feline, canine, rodent). Additional models can be trained to identify specific species.

Multiclass classification models can be used to predict:

Which category of car—sedan, truck or SUV—someone is likely to purchase, given their demographics.
A book's genre, given information about the book's author, length, characters, storyline, etc.

Appian AI Skills Use Case: Email Classification

The client receives thousands of emails everyday for customer support. Employees manually forward these emails to appropriate departments and locations based on a review of the email description and the customer's location. This process is time consuming and prone to human error. The client can automate this process using the Email Classification AI Skill that combines machine learning and automation. For the new model to be effective, the client must upload a "training set" consisting of a diverse set of emails which includes multiple examples for all desired email routing options.Once the model is trained and tested, the client can publish the model to make it available for use through the Classify Emails smart service.

Model Types Summary

Model	Prediction Type	Common Performance Metrics	Example
Regression	Predicts a numeric value	Root Mean Square Error (RMSE) Mean Absolute Error (MSE)	Predicting a home's sale price
Binary Classification	Predicts binary values (ex. true or false)	Area Under the Curve (AUC)	Predicting whether a job candidate should be offered employment
Multiclass Classification	Predicts values that belong to a limited, predefined set of permissible values	F1 Score Log Loss	Predicting a book's genre

Training Data

To create a model, you must supply the machine learning tool with training data that it will use to learn about associations between different attribute values of input data and the target attribute. The model ultimately applies the associations and patterns it found in the training data to make predictions for novel input data. There is a common adage that a model is “only as good as its training data''. If the training data is not a representative sample of the data against which it will be making predictions, the model’s performance will suffer.

Below is an example of a data structure that might be used for training data for a model designed to predict the sale price of a used car. In this use case, the column marked "Sale Price" would be identified to the model as the target attribute to predict for.

Year	Make	Model	Color	Transmission	Mileage	Previous Owners	Sale Price
1997	Ford	Mustang	Silver	Automatic	201,298	3	1,499
2013	Mazda	3	Black	Automatic	60,588	1	8,100
2005	Honda	Element	Red	Automatic	160,378	2	4,760
2009	Toyota	Camry	Blue	Manual	87,380	1	7,290

The details about how data should be ordered, formatted and uploaded to a machine learning tool for training vary depending on the specific tool being used, so refer to your tool's documentation for specific information about appropriately presenting data.

Best Practices and Tips for Training Data

The more training observations (ie. rows of data) that you provide during training, the more accurate the final model will be. This is applicable when a diverse and balanced (e.g. data between class A and B are split equally) set of training data is provided to avoid bias when making predictions. Google has documentation and a video regarding bias and machine learning that is helpful for learning more about this topic.
To the greatest extent possible, provide training data that resembles the data you expect to see in production.
Machine learning tools typically have both minimal requirements and limits regarding the size and complexity of training data. Read your tool's documentation for more details.
Some tools allow you modify the weight given to specific columns during training, or specify a "time" column if training data values are influenced by time. Read your tool's documentation for more details.

See Also

Websites:

Best Practices for Creating Training Data

Videos:

Tags: Machine Learning, Architecture

Appian Usage Insights / Appian License Tracking FAQs

joel.larin — Thu, 11 Jun 2026 21:48:12 GMT

Current Revision posted to Article by joel.larin on 6/11/2026 9:48:12 PM

Why does my application package include something called “Appian License Tracking”?

A recent update to the application led to this name change. The name used to be “Appian Usage Insights” but is now “Appian License Tracking.” The previous name persists on the AppMarket posting for recognition purposes.

The application tracks license utilization and may, in future iterations, more closely track application usage based on log availability within Appian.

How do I install the apps?

The bundled Appian License Tracking Usage Insights Installation Guide describes how to do this.

How do I upgrade to the latest version of the apps?

The bundled Upgrade Notes document describes how to do this.

How should I use the apps?

The bundled Appian License Tracking Quick Start Guide describes how to do this.

How does the app deduplicate users across environments?

Users are identified by distinct username. Their group membership and logins are considered across all environments based on the same username. For example, john.smith in Environment A is considered to be the same user as john.smith in Environment B, but not the same as john.smith@acme.com in Environment C.

I’ve run analysis on a collection run but the configuration was wrong. What can I do?

You can modify the configuration (business entities, license pools and groups, license types etc) and rerun analysis on the latest collection run as many times as you need to get the configuration right. You can only run analysis on the latest collection run, so once you load the next collection run (a few weeks later) then any further configuration changes will only apply to analysis of that next collection run data.

After my latest collection run, why do all license pools have zero allocated licenses?

After each new collection run you need to run analysis again on that latest collection run. The majority of the reports are based on the analysis of the latest collection run (except for the capacity planning report and user logins over time), so will not display any data until analysis has been run on the new collection.

How do I know which version of the app I am running?

From v1.1.0, a constant was introduced in both the Collector and the Reporting apps to display the app version. This has been updated in v2.0.0 to the following based on application name updates.

Collector App: LRDC_APPIAN_LICENSE_REPORTING_DATA_COLLECTOR_VERSION
Reporting App: ALR_APPIAN_LICENSE_REPORTING_VERSION

Information for v1.1.1 and older versions can be found below:

For the Reporting app, if the constant LMA_R_APPIAN_USAGE_INSIGHTS_REPORTING_VERSION does not exist in your app, you are either running v1.0.0 or v1.0.1. In this case, if your reporting database includes the Stored Procedure LMA_SP_USERS_BY_LICENCE_TYPE, then you are running v1.0.1.

For the Collector app, if the constant LMA_R_APPIAN_USAGE_INSIGHTS_COLLECTOR_VERSION does not exist in your app, then you are running v1.0.1 (which is identical to v1.0.0 as the Collector app did not previously change).

How should I configure reporting to see details per app but also grouped at business unit level?

From v1.1.0 onwards the Application Quick Start Guide describes how to do this.

How do I configure flat app thresholds?

From v1.1.0 onwards you can do this via the related action within any license type record. See the Application Quick Start Guide for more information.

Do you have examples or scenarios of how to set up the business entities?

Business entities are a fairly flexible concept that allow you to model usage in the most appropriate way for your business. A standard approach - that provides an overview at business unit level while allowing visibility on a per-app level too - would be to configure business entities for your organisation's larger business units, and then model the apps that belong to those business units as entity license pools. For this you would create one or more license types per app.

For example, you might configure "Finance" as a business unit, create "Fin App1 Enterprise Users", "Fin App2 Enterprise Users" and "Fin App3 Enterprise Users" as license types, and map those to the Finance business entity by creating an entity license pool for each license type within the Finance business entity. For each of those entity license pools, you would configure the groups that allow you to identify users of each of those apps (so the entity license pool for "Fin App1 Enterprise Users" might be the group "Fin App1 All Users", for instance).

When you find users that still end up in the Default entity, it's because you haven't mapped a group for them in your Business Entity - license Pool structure. The aim is to end up with no one left in the Default pool, so you know you have configured things correctly. This can take several iterations.

Why do I have to upload collection data from all of my environments at once?

Usage analysis and the resulting reports are based on a snapshot of usage across all in scope environments at the same time. Therefore, for each new collection run loaded into the reporting application, a collection for every active environment is required. These collections should generally have all been run on the same day, or close enough.

From v1.1.0 it is possible to deactivate an environment so that no further collections need to be uploaded for it. This would be used where an environment that was being reported on is no longer being used.

Can I use a non-production environment to host the reporting app?

You should consider whether your organisation allows the data that the collector application collects to be stored in a non-production environment. Additionally, as you use the application and the data stored in the reporting application grows, you should consider how you manage capacity in your chosen non-production environment.

As with any App Market app, clients are responsible for testing these apps in their own environments. When rolling out the Appian License Tracking applications within your organization, ensure that the apps are tested in your non-prod environments first according to your usual testing and release procedures.

How can I export the reports?

Currently (v1.1.0) the only export functionality included is the high level Usage by Business Entity report, which can be exported via the "Download usage by business entity" download link on the Usage Reports > Usage By Business Entity report.

How do you report on non-prod and prod licenses separately, where users need to have one license per environment?

Install the reporting app once per environment tier - e.g. a Dev reporting component, one for Test, one for Prod etc. Load only Dev environment collections into the Dev reporting component and so on.

How do I configure the collector app to gather login information for the last year?

The data collection component will collect a maximum of the last 30 days worth of login information. If you have run the collector in the last 30 days, it will collect the login information since the last time it ran. Over time as the collector is run (at least every 30 days) and the collections are loaded into the reporting component, you will build up login data across a longer period. The application doesn't support collecting older, compressed login audit data. This doesn't prevent the allocation of users to license pools (which is based on the most recent group membership collections). But it does mean that the login information displayed in the app will only become more meaningful as collections are built up over time.

Tags: monitoring

Performance Testing Initiation Best Practices Checklist

joel.larin — Thu, 11 Jun 2026 21:46:29 GMT

Current Revision posted to Article by joel.larin on 6/11/2026 9:46:29 PM

These Performance Testing Initiation Best Practices allow teams to identify if they have correctly designed their performance tests before test execution

Stakeholder Alignment

Item	Importance	Status
Business Stakeholders Identified	High
IT Stakeholders Identified	High
Performance Test Architect Identified	High
Performance Test Engineer Identified	Medium
Dedicated Performance Test Environment Identified	High

Non-Functional Requirements

Item	Importance	Status
Average Transactions per day for each key flow	High
Average Transactions per user for each key flow	High
Peak Transactions during peak hour/minute for each key flow	High
Data Generated in each table identified for 18+ months past go live	High
Determine the need for a Performance Test, Load Test, Stress Test or Endurance Test based on the above requirements.	High

Acceptance Criteria

Item	Importance	Status
Targets for 90 percentile Response Time Identified	High
Targets for transaction throughput identified for each respective test (Performance, Load, Stress and Endurance) based on estimated volumes.	High

Test Design

Item	Importance	Status
Test design incorporates realistic usage scenarios including “think time”.	High
Test design incorporates variability and realistic test data	High

Tags: checklists, Performance, Architecture

Deleting Data in Appian Applications

joel.larin — Thu, 11 Jun 2026 21:45:32 GMT

Current Revision posted to Article by joel.larin on 6/11/2026 9:45:32 PM

Introduction

Are you having trouble finding data to debug an issue? Are your queries to a transaction table slow? Did you get a requirement to display activity history for a user? Your Appian application’s data model design and data deletion strategy can have a major role in how these questions or concerns can be addressed. When designing the data model for your Appian application, there are different approaches to consider for data deletion use cases. The approach you choose will probably depend on the nature of the data, the number of transactions, and the business rules associated with the use case. The most common approaches include:

hard deletes - actually deleting rows from the table.
soft deletes - marking rows as deleted using a flag column e.g. isDeleted or isActive.
audit log - creating a separate audit table for recording the nature of transactions taking place on the original table.

This article describes the pros and cons of each deletion approach and provides recommendations on when to use these approaches. For the purposes of this article, the relational database data model from the Quote to Order case study is referenced for examples.

Figure 1: Quote to Order ERD

Hard Deletes

The term ”hard delete” is generally accepted to describe the irrevocable removal of data. When a value or row is hard-deleted from a table, it means a DELETE operation has been executed on a row in the table. This is typically the easiest and fastest option for developers, independent of business rules.

NOTE: It is recommended to use the Delete from Data Store Entities smart service for hard deleting data from Appian applications. Make sure the deletes are based on an indexed field (ideally the primary key field). You may run the EXPLAIN statement to see the execution plan prior to the delete. If you are deleting in bulk and there’s HA setup at the database layer, it’s preferred to purge in batches (limit to 1000 rows per batch) and during off hours to minimize the impact (database locking) on the application . Be aware of the foreign key constraints and cascade attribute settings in the database schema and make sure your data is backed up prior to the delete in case you need to restore it.

Pros

Transaction times are faster.
Lets you design simple unique and check constraints on table columns.
Better data integrity and cardinality of columns in tables.
Design allows for creating foreign keys with cascading delete.

Cons

Risk of data loss due to defects in the application.
Lack of traceability of data for business reporting or technical debugging.

When to Use

A hard delete strategy is better suited for transactional tables with possibly high transaction volume and which do not need historical data for business or technical purposes.
In reference to the Quote to Order tables, an example of a hard delete would be deleting a draft order from the QTOT_ORDER table when a user cancels/deletes a draft order.

Soft Deletes

By contrast to a hard delete, data is typically retained according to a soft delete strategy. Instead of deleting the data, the table row to be soft deleted is marked with a value in a dedicated column.. This option seems less risky in terms of losing data due to hard deletes but could be risky in terms of unintended data showing up in reports or other parts of the application or compromising the performance of the table.

Pros

Safer approach in general from a perspective of making sure data is not lost.
Easy to undo delete operations or reactivate the row if needed.
Entire history of the table can be traced in a single table.

Cons

Tables can grow rapidly and can lead to unnecessary disk usage and bad performance.
Complicates maintenance of data integrity due to the need of complex unique indexes and check constraints.
Risk of defects being introduced due to designers missing to code the isActive flag into read/write database operations from the application e.g. database view cdts/tables missing the isActive flag field, CDT value used in the write to database smart service missing a value for the isActive flag, etc.
Design to support ad-hoc reporting is demanding, in terms of development, with the need to have database views to filter data. Significantly complex views would require materialized views.
Low cardinality of the isActive flag column might impact performance of data retrieval despite indexing on the table, especially when 99.99% of the rows have inactive status.

When to Use

Consider a soft delete approach for operational or reference data as opposed to transactional data or relational mapping tables.
For reference data tables instead of creating just an isActive flag to indicate a deleted entry, a START_DATE and END_DATE pair of columns provides a more granular control over retrieval of the data and thus the possibility of viewing the historical usage of your data. See QTOT_REFERENCE table in the ERD above.

Audit Log

A less invasive approach to deleting data in a table involves creating an audit log of delete operations on the table. It is very common for application designers to have an auditing strategy to record changes done by users in the application. So the audit log approach for recording deletes that happen on a table, as a result of a user’s action or as a business rule, fits right into that strategy. Detailed guidance on implementing audit tables for Appian applications can be found in the Auditing Guidance docs and the Field Level Auditing play.

Pros

Better data reporting capability for original data and historical reporting of audit data.
Separate table for audit allows the original table to perform better due to less accumulation of unnecessary data.
Troubleshooting data issues becomes easier given the data in audit tables.
Audit tables can have more detail than just a isActive/isDeleted flag e.g. old value, new value, last updated on, update operation - create, update, delete, etc. See QTOT_ACCOUNT_AUDIT table in the ERD above.

Cons

Longer development time.

When to Use

For transactional tables e.g. QTOT_ACCOUNT or QTOT_ORDER use the hard delete approach in conjunction with an audit table implementation.
Applications typically have event tables to track business events in general. The audit for delete operations can be stored in such event tables. In such implementations, designers would have to transform the data from the original table structure to the event table structure or some other structure of the audit table. Using a JSON structure for the audit data eliminates the need to transform it and makes the implementation easier.

Hybrid Approach

The Quote to Order data model includes the table QTOA_HISTORICAL_ORDER as part of a data archival strategy. This type of strategy helps with overall application performance. “Mirror” tables that match the structure of the original transaction tables are core to this approach. With these tables in place, a design can be employed in which the application switches between them to access appropriate data depending on its age. For example, in the Quote to Order data model the QTOT_ORDER table has a corresponding QTOA_HISTORICAL_ORDER table. Data from the QTOT_ORDER table is archived to the QTOA_HISTORICAL_ORDER table if it is older than six months and eventually to long term storage after it ages out further. This keeps the size of the QTOT_ORDER table reasonably low leading to better performance.

Conclusion

A data deletion strategy should be based on the nature of the data and the business case. In summary, use a hybrid implementation approach wherein:

Hard deletes are performed on transaction tables in conjunction with audit tables tracking the delete operations. The transaction tables are archived periodically based on the age of the data.
Soft deletes are performed on operational or reference tables by marking the data with columns such as START_DATE and END_DATE.

Tags: database, Architecture

Why Process Automation is Right for Your Business

Devon — Fri, 30 Jan 2026 21:09:09 GMT

Current Revision posted to Article by Devon on 1/30/2026 9:09:09 PM

Organizations are transforming at a breakneck pace, driven by rapidly evolving consumer behavior and expectations. New, digitally enabled businesses are upending entire industries and the COVID-19 pandemic has only accelerated the trends. According to an executive Global Survey done by McKinsey, more than half of respondents said they were “investing in technology for competitive advantage or refocusing their entire business around digital technologies.” Compare that to the same survey done pre-pandemic in 2017, where only around 10% of respondents held the same view of technology.

The problem is most businesses continue to rely on legacy enterprise systems. These systems are often complex and difficult to change. Over time, they often include patched or jerry-rigged measures to address a myriad of issues. With all this change, one thing is clear—you can’t rely on inflexible technologies and business practices. You need adaptable systems that can meet the needs of today and the demands of tomorrow.

Is traditional software development up to the task?

Organizational success has become increasingly dependent on technology. Even “non-tech” companies now succeed or fail based on the capabilities of their digital infrastructure. However, the typical technology stack is often complex and opaque. It’s hard to use and years worth of ad-hoc changes have made it even harder to revise. This is only made worse by slow and expensive software development practices.

In today’s technological climate, the ability to quickly develop and implement new processes is essential. Whether you’re a hotel providing touchless check-in or a retailer fostering a more efficient and personal online shopping experience-—brands that empower customers with technology are being rewarded. This trend has only been accelerated further by the onset of the pandemic, where agility and adaptability have in some cases meant the difference between thriving and just surviving. If you were quick to put in place contactless protocols, you could get back to work faster than those with inflexible systems.

Given this increasing need for agile and flexible software development, traditional methods of hand-coding software can’t keep up. The traditional software development model consists of large, centralized teams of specialized developers. These teams work within highly planned and rigid processes and fail to adequately address the complex automation needs of today's digital enterprise. If you're stuck with outmoded or rigid legacy processes, you won't be able to adapt to your users changing needs and may risk losing them. Compounding the problem are a complex set of circumstances, including:

Unprecedented new operating environments. The COVID-19 pandemic ushered in a world of continuous disruption and adaptation. It forced organizations to create processes for remote work. It also called for new safety, testing and tracking protocols.
Changing regulatory requirements. From environmental protections to accounting standards—new rules and regulations result in costly workflow modifications.
Evolving expectations. Customers and employees expect high-quality, streamlined and intuitive user experiences. The bar is now set by their favorite brands at home, rather than those at work. Companies must continually enhance the customer journey by leveraging data and digitizing functions.
Global growth opportunities. Global markets enable organizations to sell and source materials in new territories. Technology is not only making new products and services possible, but also changing how you market and deliver them. But, without the time and resources to invest, businesses risk missing out.

Navigating all this uncertainty requires more streamlined, automated digital workflows. And this must be done as rapidly and cost-effectively as possible.

Low-Code: Flexible, Resilient and Adaptable

To thrive in this new reality, enterprise software today must be flexible, resilient and adaptable. You need customizable automation that can change according to dynamic needs. You also need automated workflows that are custom mapped to unique goals and real-world challenges, not just the most common scenarios. Most of all, you need to increase speed and lower the cost of development.

Fortunately, low-code development platforms reduce the burden of building enterprise applications. Meaning you can now build apps and streamline workflows faster and cheaper than ever before. Low-code lets you leverage existing technology investments, and extend capabilities. It reduces buildout time and cost, and enables you to effectively automate functions to compete in this new paradigm. An Economic Impact Study conducted by Forrester found that customers using Appian’s low-code platform:

Accelerated application creation by 17x
Improved time-to-value of applications by 50%
Realized a 389% return on investment (ROI)

Those outcomes were made possible by two distinct advantages low-code offers to developers: Speed and Ease of Use. Low-code allows developers to work rapidly by selecting from a library of ready-made tools or empowering them to make their own reusable tools. In addition, low-code removes the barrier to entry to software development. Rather than each developer needing a solid command of Java, HTML, CSS, PHP, SQL (not to mention third party API frameworks ), each team member only needs to know Appian, which creates bandwidth for what’s most important: solving real business problems.

At its core, low-code does away with much of the time and resource intensive high-code development requirements. Appian pioneered and continues to lead the low-code development space by providing best-of-breed integrated development tools, in addition to a full suite of tools designed to help you unify your data, build apps, and automate your business.

Tags: Vision

Innovate with Process Automation

Devon — Fri, 30 Jan 2026 21:07:06 GMT

Current Revision posted to Article by Devon on 1/30/2026 9:07:06 PM

To be competitive today, it’s not enough for businesses to be efficient; they also need to innovate according to their own unique vision. They need to offer dynamic products and services that can respond to the distinct demands and requirements of their users. However, building a new product or service is a time and resource intensive undertaking. This is even more pronounced when developing solutions that don't fit nicely into pre-established product delivery pipelines. Manual tasks, inflexible processes and complicated business rules all get in the way of offering unconventional or game-changing product lines.

Innovation, by definition, requires some coloring outside the lines. And this is where low-code can make all the difference, by helping businesses automate their processes and integrate more flexible delivery models.

Innovation for differentiation

In the sometimes conservative and highly regulated world of finance, innovation can be hard to come by. But institutions with an eye towards digital transformation are increasingly differentiating themselves in a highly competitive market. Let’s take a look at SEB Investor Services, one of the leading providers of asset servicing to institutional investors in the Nordic region, to see how low-code drives innovation.

SEB saw an opportunity to offer its clients services outside the traditional securities most banks provide, namely shares, bonds, derivatives, and funds. They wanted to add alternative assets–wind and solar, private equity, venture capital holdings–to their portfolio, so as to better serve the diverse needs of their clients. In the past, SEB offered relatively few alternative assets due to the manual labor and high degree of operational difficulty required to provide the service. They needed to find a way to automate the handling of these assets, without having to bring in a full team of developers to create and maintain the service.

That’s when the SEB team identified low-code as the perfect solution to quickly and efficiently move forward with their plan. Using the Appian platform, they were able to reconfigure and automate complex business rules, as well as the unique workflows and data structures associated with alternative assets. In an interview given to PostTrade 360°, SEB Product Manager Frederik Söderlund described the process of using low code to realize the project:

The big projects cost big money – with large project groups, consultants and testing. But when you start from a blank sheet today, using new technology based on blocks that you assemble in lego style, with pre-defined integrations and self-testing capabilities…it gets so much easier.

Fredrik Söderlund, Product manager for portfolio solutions at SEB Investor Services/LCFI

In addition to automating the handling of alternative assets, SEB was also able to employ AI-powered IDP (Intelligent Document Processing) to help extract and interpret investment data. This holistic approach enabled them to not only increase the number of alternative assets available to their clients, but to maximize value from returns on those investments. By partnering with Appian, SEB was able to take one of finance’s least standardized processes and unlock new, value-added product offerings from it.

Disruptive innovation

Disruption shouldn’t be a business goal in and of itself. But innovation often has the side effect of disrupting those arenas that are no longer providing an optimal experience. Since the advent of ridesharing companies, the commonly held belief was that congestion and pollution would decrease as more single drivers opted for these services. However, a study conducted by Researchers from the University of Kentucky and the San Francisco County Transportation Authority found that transportation network companies (TNC’S) were actually the largest contributor to increased congestion in cities like San Francisco.

Enterprise Holdings, Inc, manager of the largest and most diverse privately-owned fleet of vehicles in the world, identified an opportunity to innovate within the ridesharing industry. The plan was to target a traditionally underserved market of vanpool commuters, namely people traveling to work in groups of more than 3 or 4. The goal was to provide these commuters with a lower-cost, more environmentally friendly commuting option.

However, existing systems within the company could not accommodate a new business with a radically different operating model and workflow. Building a custom application using traditional methods would have taken years, causing Enterprise to miss their window of opportunity. Using Appian, Enterprise was able to realize this vision and create Commute, the company’s vanpooling service, in just 4 months.

Commute programs are organized by an employer and typically consist of 4 to 15 coworkers traveling together. Commuters coordinate a central meeting location, board a late-model, low-mileage van or SUV from the company’s fleet, and take turns driving to and from work. This gives commuters time to read, relax, catch up on some work, or even stream their favorite shows with WIFI enabled vans.

We adopted Appian's platform for Enterprise Rideshare because it combines the best of business process management, social business, mobile access and cloud deployment. The result is a truly modern business management platform that supports our objective of providing commuters with a smarter, better way to get to work.

Ryan Johnson, Assistant Vice President of Enterprise Holdings

Commute not only helps workers reduce the financial burden of commuting, but also lets them arrive at work less stressed, leading to higher productivity. After partnering with Appian, Commute has scaled to operate more than 11,000 vanpools in 45 states. It removes more than 40,000 vehicles off the road every day and eliminates an estimated 900 million commuter miles annually. To top it all off, the program also reduces more than 695 millions pounds of carbon emissions annually.

We’ve seen how low-code can be a driver for innovation, whether in more historically conservative fields such as finance, or in burgeoning industries such as ridesharing. Low-code enables businesses to work more quickly, efficiently, and cost effective. Dynamic business conditions and evolving user demands will always put pressure on businesses to innovate. With low-code integrated into their digital strategy, imaginative organizations can respond quickly and decisively, while continuing to push the envelope on their personal strategic vision.

Tags: Vision

Process Automation Team Essentials

Devon — Fri, 30 Jan 2026 21:06:28 GMT

Current Revision posted to Article by Devon on 1/30/2026 9:06:28 PM

One of the most common questions we receive focuses on how to structure an organization for low-code success. There isn’t a one-size-fits-all answer to this question, but we do have a few guidelines for getting started. The most important part is thinking of your Appian-trained workforce as a team, with mutually supportive roles and responsibilities across the organization.

At Appian, we think a successful team is a combination of a few select roles that each play an important role in a project’s success:

Leaders
Planners
Builders
Administrators

Let’s dig a little bit deeper into each of these team roles, why they are important, and what they need to know.

Appian Leaders

For our purposes, leaders include business stakeholders, managers, or executives who need awareness of low-code automation capabilities but aren't heavily involved in the development process. They are, however, stakeholders and decision makers responsible for an organization’s success. They often control the budget, people, and determine the desired outcomes of projects. To be successful, these leaders need to understand the capabilities of Appian and how it can solve their problems.

Leaders also need to understand how to source, train, and structure their teams for ongoing success, and they’ll usually want to know what pitfalls to look out for when automating portions of their business.

See our Vision pillar for resources geared towards Appian Leaders.

Appian Planners

The planner role defines the processes to be automated, prioritizes development efforts, and ensures coordination with other business units. The most common job titles we see functioning in the planner role include business analysts, product owners, project managers, scrum masters, and UX designers. Some organizations have distinct team members assigned to each role, while others may have a single individual functioning across multiple roles. At a minimum, you should plan to include both a product owner and an analyst as part of your Appian team. This will ensure your organization is positioned for success.

Appian planners need a strong understanding of the Appian delivery methodology and a basic understanding of how Appian objects come together to make applications. See our Delivery pillar for more resources geared towards Appian Planners.

Appian Builders

Builders, or developers, are the core of any Appian delivery team. Their primary job is taking requirements produced by the analysts, prioritizing them with the product owner, and converting them into applications using the Appian process automation platform. Functionally, the role of an Appian builder can be broken down into the following positions:

Low-Code Developers
Lead Developers
Quality Assurance

Appian strongly recommends a Team of 3 structure for most projects, with larger projects or initiatives distributed across multiple teams. Each team should be cross-functional in so much as any member of the team can take on any task when needed. Naturally, some team members will be stronger in certain skills than others, but we’ve found that high-performing, multi-disciplinary teams are best suited for success.

For example, a low-code developer often falls into the “Developer and…” paradigm. This means that a particular team member might fall into a dual role as a low-code developer, in addition to acting as an architect, scrum master, UX lead, or test manager. When building these small cross-functional teams, it’s important to look for team members that have skills outside of their primary role or function. Whether that’s an interest in data models, integrations, or process mining, looking out for complimentary skills is the best way to establish a versatile low-code team.

Administrators

Administrators own responsibility for the Appian system and supporting infrastructure. This includes overseeing server admins, database administrators, IT staff, or anyone supporting the application’s backend. Administrators are most often concerned with the security implications of the Appian platform and how it interacts with their internal systems. This includes things such as data management, web APIs, user accounts and more.

Although administrators aren’t usually involved in development themselves, they work closely with lead developers to define technical requirements and boundaries. To this end, administrators should pursue a basic level of training to better understand the terminology and underlying infrastructure of the Appian platform.

Application Administrators

Application Administrators are employees of the customer organization responsible for the maintenance and support of individual applications. They’re typically in charge of user management, performing basic clean-up and housekeeping activities, and serve as the first layer of support to triage tickets and issues.

At a high level, Application Administrators understand how Appian objects interact with one another to form an application, but aren’t developers themselves. They perform basic troubleshooting activities, and are knowledgeable on navigating Appian support systems to get resolution on more complicated issues. Application Admins are also familiar with tools including Health Check, Health Dashboard, and MyAppian.

To support this role, we developed the Appian Application Administrator course, available through Appian Academy.

Tags: People

Shared Object Management Overview

joel.larin — Wed, 29 Oct 2025 14:20:10 GMT

Current Revision posted to Article by joel.larin on 10/29/2025 2:20:10 PM

Overview

This document provides guidance on what shared objects are, how to identify them, how to secure them and how to update them in a manner that is safe and responsible. When used with care, shared objects provide a layer of reusable components for the entire platform to fast forward the development of every application.

Common objects are those that are used across the platform in multiple applications. They could provide generic, routinely-used functionality for many applications or they could be more specialized and used for a specific set of applications only.

For example, a user sync module that pulls user information from Workday would fall into the first category, while an Engagement record will fall into the latter. Avoid objects with complex or specific business logic unless they apply to all referring applications and aren’t likely to differ between applications in the future. In general, the more well defined and structured the inputs and outputs of an object are, the easier it will be to reuse amongst different applications. The rules for which objects to place into a common objects application can differ from one organization to another, however it is important to consider the value the component will provide compared to the additional time to maintain, test, and coordinate among groups utilizing the object.

In some situations, having multiple common object applications, each specific to their scope, will make managing changes easier for those who utilize them. As an example, a department may have multiple applications to manage new product approvals, customer onboarding, and periodic customer review processes which share common data objects, expressions, and integrations. Some of those components may be specific to the department and others are used globally. For each common objects application that your organization decides to create, ensure the following are documented:

Description of the purpose and scope
Owner or owning group
Implementation usage instructions
Who to notify when updates are made

Object Types

Object type	Criteria	Example
Expressions Decisions	Logic containing reusable functionality	Email address validation Mailing address formatting Display name formatting
Data Types Data Stores Query Rules Constants	Reference data across applications	List of States/Countries User details
Interfaces	Common interface sections	Mailing address input form User details input form
Web APIs	Reference data exposed externally	User details
Records	Records referenced by or containing data from multiple applications or synced records representing reference data	Study Engagement
Process Models	Logic containing reusable functionality	User synchronization
Connected Systems Integrations	Reusable connections to external systems	Transfer documents

Identification and Cataloging

The identification of common objects is the responsibility of the application development team and the Center of Excellence (CoE). Some heuristics for identifying common objects could include:

Is the functionality going to be accessed by all platform users?
Are other applications going to leverage the same functionality? e.g. vendor search?
Is the functionality agnostic of the application it is in? e.g. a list of countries
What is the potential scope of a common object; eg. Department, Region, Global

These questions can be asked before, during and after the development cycle, but the sooner common functionality is identified the easier it is to classify it and leverage it across the platform.

Once the team identifies the object(s), they should be moved to the appropriate application and renamed with the appropriate application prefix. Detailed descriptions for Appian objects are important to ensure that changes do not break the contract between the shared object and the corresponding dependent object. For expressions and interfaces, ensure common objects have test cases defined so that during updates, they can be tested for backwards compatibility. Rule inputs should also be given descriptions so that Designers can easily understand their intended use. Teams working on new applications should always consult the Common Objects applications in order to identify any functionality that could be reused. Proper naming conventions and descriptions will make these objects easier to search and discover.

Security and Ownership

Since common objects are shared between different applications, changes to these objects can have a wide impact. Changes that benefit one app could potentially break another. Therefore, updates to common objects need to be taken with care after sufficient impact analysis.

In programs with multiple teams, we recommend securing the objects to a specific designer group (and revoking sys admin access from designers). In such situations, while all objects need to have an admin group defined (see Health Check for more details), common objects especially need to have correct security set up with one group as the object admins and other designer groups as viewers – so these objects can be used but not edited.

Common Object Use and Maintenance

Using a common object is very easy – just reference it in your application. Note that if the common object version you wish to utilize has not been deployed to your desired environment already, you may need to use a separate package to deploy it, if it is only part of the common object application but not your own.

When an object needs to be edited, make a change request to the owners. Where appropriate, consider notifying the impacted teams if the updates will result in changes to the end user behavior or will require consumers of the common objects to opt into the new functionality being developed. Who makes the change depends on your organization (see Example Process) but we recommend that owners delegate the edits to the change requestor (application team). Appropriate testing and reviews should occur before promoting to higher environments. An extra emphasis should be placed on regression testing to ensure the changes will be backwards compatible.

Example Process

Steps to Modify Common Objects

When an object is modified in a common app, follow the below steps:

Request to make a change from the object owner(s).
Before making the change, check for dependencies on the object to see which teams could be impacted by the rule modification. Reach out to the associated owners to ensure the change is compatible before proceeding.
The owner grants edit access to the application(s).
If a common object needs to be modified that already has changes in progress, check to see if the change has already been deployed throughout the environments. More complex objects, like records, have a higher likelihood of a change in progress. If that is the case, reach out to the developer associated with the object and ensure the proposed changes are compatible before proceeding. Other measures may have to be taken, e.g. feature toggles, to get the changes deployed without breaking precedents.
Owner revokes edit access to the application(s).

Tags: Delivery, Architecture

Shared Object Management Overview

joel.larin — Wed, 29 Oct 2025 14:19:56 GMT

Revision 7 posted to Article by joel.larin on 10/29/2025 2:19:56 PM

Overview

"Common objects are those that are used across the platform in multiple applications. They could provide generic, routinely-used functionality for many applications or they could be more specialized and used for a specific set of applications only. "

Description of the purpose and scope
Owner or owning group
Implementation usage instructions
Who to notify when updates are made

Object Types

Object type	Criteria	Example
Expressions Decisions	Logic containing reusable functionality	Email address validation Mailing address formatting Display name formatting
Data Types Data Stores Query Rules Constants	Reference data across applications	List of States/Countries User details
Interfaces	Common interface sections	Mailing address input form User details input form
Web APIs	Reference data exposed externally	User details
Records	Records referenced by or containing data from multiple applications or synced records representing reference data	Study Engagement
Process Models	Logic containing reusable functionality	User synchronization
Connected Systems Integrations	Reusable connections to external systems	Transfer documents

Identification and Cataloging

The identification of common objects is the responsibility of the application development team and the Center of Excellence (CoE). Some heuristics for identifying common objects could include:

Is the functionality going to be accessed by all platform users?
Are other applications going to leverage the same functionality? e.g. vendor search?
Is the functionality agnostic of the application it is in? e.g. a list of countries
What is the potential scope of a common object; eg. Department, Region, Global

These questions can be asked before, during and after the development cycle, but the sooner common functionality is identified the easier it is to classify it and leverage it across the platform.

Security and Ownership

Common Object Use and Maintenance

Example Process

Steps to Modify Common Objects

When an object is modified in a common app, follow the below steps:

Request to make a change from the object owner(s).
Before making the change, check for dependencies on the object to see which teams could be impacted by the rule modification. Reach out to the associated owners to ensure the change is compatible before proceeding.
The owner grants edit access to the application(s).
If a common object needs to be modified that already has changes in progress, check to see if the change has already been deployed throughout the environments. More complex objects, like records, have a higher likelihood of a change in progress. If that is the case, reach out to the developer associated with the object and ensure the proposed changes are compatible before proceeding. Other measures may have to be taken, e.g. feature toggles, to get the changes deployed without breaking precedents.
Owner revokes edit access to the application(s).

Tags: Delivery, Architecture

Appian Usage Insights / Appian License Tracking FAQs

joel.larin — Tue, 10 Jun 2025 23:12:18 GMT

Revision 10 posted to Article by joel.larin on 6/10/2025 11:12:18 PM

Why does my application package include something called “Appian License Tracking”?

The application tracks license utilization and may, in future iterations, more closely track application usage based on log availability within Appian.

How do I install the apps?

The bundled Appian License Tracking Usage Insights Installation Guide describes how to do this.

How do I upgrade to the latest version of the apps?

The bundled Upgrade Notes document describes how to do this.

How should I use the apps?

The bundled Appian License Tracking Quick Start Guide describes how to do this.

How does the app deduplicate users across environments?

I’ve run analysis on a collection run but the configuration was wrong. What can I do?

After my latest collection run, why do all license pools have zero allocated licenses?

How do I know which version of the app I am running?

From v1.1.0, a constant was introduced in both the Collector and the Reporting apps to display the app version. This has been updated in v2.0.0 to the following based on application name updates.

Collector App: LRDC_APPIAN_LICENSE_REPORTING_DATA_COLLECTOR_VERSION
Reporting App: ALR_APPIAN_LICENSE_REPORTING_VERSION

Information for v1.1.1 and older versions can be found below:

How should I configure reporting to see details per app but also grouped at business unit level?

From v1.1.0 onwards the Application Quick Start Guide describes how to do this.

How do I configure flat app thresholds?

From v1.1.0 onwards you can do this via the related action within any license type record. See the Application Quick Start Guide for more information.

Do you have examples or scenarios of how to set up the business entities?

Why do I have to upload collection data from all of my environments at once?

Can I use a non-production environment to host the reporting app?

How can I export the reports?

How do you report on non-prod and prod licenses separately, where users need to have one license per environment?

Install the reporting app once per environment tier - e.g. a Dev reporting component, one for Test, one for Prod etc. Load only Dev environment collections into the Dev reporting component and so on.

How do I configure the collector app to gather login information for the last year?

Tags: monitoring

Appian Usage Insights / Appian License Tracking FAQs

joel.larin — Tue, 10 Jun 2025 23:10:55 GMT

Revision 9 posted to Article by joel.larin on 6/10/2025 11:10:55 PM

Why does my application package include something called “Appian License Tracking”?

The application tracks license utilization and may, in future iterations, more closely track application usage based on log availability within Appian.

How do I install the apps?

The bundled Appian License Tracking Usage Insights Installation Guide describes how to do this.

How do I upgrade to the latest version of the apps?

The bundled Upgrade Notes document describes how to do this.

How should I use the apps?

The bundled Appian License Tracking Quick Start Guide describes how to do this.

How does the app deduplicate users across environments?

I’ve run analysis on a collection run but the configuration was wrong. What can I do?

After my latest collection run, why do all license pools have zero allocated licenses?

How do I know which version of the app I am running?

From v1.1.0, a constant was introduced in both the Collector and the Reporting apps to display the app version. This has been updated in v2.0.0 to the following based on application name updates.

Collector App: LRDC_APPIAN_LICENSE_REPORTING_DATA_COLLECTOR_VERSION
Reporting App: ALR_APPIAN_LICENSE_REPORTING_VERSION

Information for v1.1.1 and older versions can be found below:

How should I configure reporting to see details per app but also grouped at business unit level?

From v1.1.0 onwards the Appian Usage Insights Quick Start Guide describes how to do this.

How do I configure flat app thresholds?

From v1.1.0 onwards you can do this via the related action within any license type record. See the Appian Usage Insights Quick Start Guide for more information.

Do you have examples or scenarios of how to set up the business entities?

Why do I have to upload collection data from all of my environments at once?

Can I use a non-production environment to host the reporting app?

As with any App Market app, clients are responsible for testing these apps in their own environments. When rolling out the Appian Usage Insights applications within your organisation, ensure that the apps are tested in your non-prod environments first according to your usual testing and release procedures.

How can I export the reports?

How do you report on non-prod and prod licenses separately, where users need to have one license per environment?

Install the reporting app once per environment tier - e.g. a Dev reporting component, one for Test, one for Prod etc. Load only Dev environment collections into the Dev reporting component and so on.

How do I configure the collector app to gather login information for the last year?

Tags: monitoring

Appian Usage Insights / Appian License Tracking FAQs

joel.larin — Tue, 10 Jun 2025 23:09:42 GMT

Revision 8 posted to Article by joel.larin on 6/10/2025 11:09:42 PM

Why does my application package include something called “Appian License Tracking”?

The application tracks license utilization and may, in future iterations, more closely track application usage based on log availability within Appian.

How do I install the apps?

The bundled Appian License Tracking Usage Insights Installation Guide describes how to do this.

How do I upgrade to the latest version of the apps?

The bundled Upgrade Notes document describes how to do this.

How should I use the apps?

The bundled Appian License Tracking Quick Start Guide describes how to do this.

How does the app deduplicate users across environments?

I’ve run analysis on a collection run but the configuration was wrong. What can I do?

After my latest collection run, why do all license pools have zero allocated licenses?

How do I know which version of the app I am running?

From v1.1.0, a constant was introduced in both the Collector and the Reporting apps to display the app version. This has been updated in v2.0.0 to the following based on application name updates.

Collector App: LRDC_APPIAN_LICENSE_REPORTING_DATA_COLLECTOR_VERSION
Reporting App: ALR_APPIAN_LICENSE_REPORTING_VERSION

Information for v1.1.1 and older versions can be found below:

How should I configure reporting to see details per app but also grouped at business unit level?

From v1.1.0 onwards the Appian Usage Insights Quick Start Guide describes how to do this.

How do I configure flat app thresholds?

From v1.1.0 onwards you can do this via the related action within any license type record. See the Appian Usage Insights Quick Start Guide for more information.

Do you have examples or scenarios of how to set up the business entities?

Why do I have to upload collection data from all of my environments at once?

Can I use a non-production environment to host the reporting app?

How can I export the reports?

How do you report on non-prod and prod licenses separately, where users need to have one license per environment?

Install the reporting app once per environment tier - e.g. a Dev reporting component, one for Test, one for Prod etc. Load only Dev environment collections into the Dev reporting component and so on.

How do I configure the collector app to gather login information for the last year?

Tags: monitoring

Appian Usage Insights / Appian License Tracking FAQs

joel.larin — Tue, 10 Jun 2025 23:08:26 GMT

Revision 7 posted to Article by joel.larin on 6/10/2025 11:08:26 PM

Why does my application package include something called “Appian License Tracking”?

The application tracks license utilization and may, in future iterations, more closely track application usage based on log availability within Appian.

How do I install the apps?

The bundled Appian License Tracking Usage Insights Installation Guide describes how to do this.

How do I upgrade to the latest version of the apps?

The bundled Upgrade Notes document describes how to do this.

How should I use the apps?

The bundled Appian License Tracking Quick Start Guide describes how to do this.

How does the app deduplicate users across environments?

I’ve run analysis on a collection run but the configuration was wrong. What can I do?

After my latest collection run, why do all license pools have zero allocated licenses?

How do I know which version of the app I am running?

From v1.1.0, a constant was introduced in both the Collector and the Reporting apps to display the app version. This has been updated in v2.0.0 to the following based on application name updates.

Collector App: LRDC_APPIAN_LICENSE_REPORTING_DATA_COLLECTOR_VERSION
Reporting App: ALR_APPIAN_LICENSE_REPORTING_VERSION

Information for v1.1.1 and older versions can be found below:

How should I configure reporting to see details per app but also grouped at business unit level?

From v1.1.0 onwards the Appian Usage Insights Quick Start Guide describes how to do this.

How do I configure flat app thresholds?

From v1.1.0 onwards you can do this via the related action within any license type record. See the Appian Usage Insights Quick Start Guide for more information.

Do you have examples or scenarios of how to set up the business entities?

Why do I have to upload collection data from all of my environments at once?

Can I use a non-production environment to host the reporting app?

How can I export the reports?

How do you report on non-prod and prod licenses separately, where users need to have one license per environment?

Install the reporting app once per environment tier - e.g. a Dev reporting component, one for Test, one for Prod etc. Load only Dev environment collections into the Dev reporting component and so on.

How do I configure the collector app to gather login information for the last year?

Tags: monitoring

Appian Usage Insights FAQs

joel.larin — Tue, 10 Jun 2025 23:04:23 GMT

Revision 6 posted to Article by joel.larin on 6/10/2025 11:04:23 PM

Why does my application package include something called “Appian License Tracking”?

The application tracks license utilization and may, in future iterations, more closely track application usage based on log availability within Appian.

How do I install the apps?

The bundled Appian Usage Insights Installation Guide describes how to do this.

How do I upgrade to the latest version of the apps?

The bundled Upgrade Notes document describes how to do this.

How should I use the apps?

The bundled Appian Usage Insights Quick Start Guide describes how to do this.

How does the app deduplicate users across environments?

I’ve run analysis on a collection run but the configuration was wrong. What can I do?

After my latest collection run, why do all license pools have zero allocated licenses?

How do I know which version of the app I am running?

From v1.1.0, a constant was introduced in both the Collector and the Reporting apps to display the app version. If the constants LMA_R_APPIAN_USAGE_INSIGHTS_COLLECTOR_VERSION or LMA_R_APPIAN_USAGE_INSIGHTS_REPORTING_VERSION do not exist in your app, you are either running v1.0.0 or v1.0.1. In this case, if your reporting database includes the Stored Procedure LMA_SP_USERS_BY_license_TYPE, then you are running v1.0.1.

How should I configure reporting to see details per app but also grouped at business unit level?

From v1.1.0 onwards the Appian Usage Insights Quick Start Guide describes how to do this.

How do I configure flat app thresholds?

From v1.1.0 onwards you can do this via the related action within any license type record. See the Appian Usage Insights Quick Start Guide for more information.

Do you have examples or scenarios of how to set up the business entities?

Why do I have to upload collection data from all of my environments at once?

Can I use a non-production environment to host the reporting app?

How can I export the reports?

How do you report on non-prod and prod licenses separately, where users need to have one license per environment?

Install the reporting app once per environment tier - e.g. a Dev reporting component, one for Test, one for Prod etc. Load only Dev environment collections into the Dev reporting component and so on.

How do I configure the collector app to gather login information for the last year?

Tags: monitoring

Integrating using Web Services

joel.larin — Tue, 10 Jun 2025 17:41:52 GMT

Current Revision posted to Article by joel.larin on 6/10/2025 5:41:52 PM

Appian can use Web Services to integrate with external systems as a service provider (other systems calling Appian) or as a client (calling other systems from Appian). Most common protocols and standards are supported by default, but you can extend the platform using Appian's plug-in framework.

The recommended approach for Appian to access other systems is through use of the Integration Object.
The recommended approach for other systems to access Appian is through the Web API Object.

Calling Other Systems from Appian

Anytime Appian calls another system using supported authentication and methods, it should be configured using an Integration Object, paired with a Connected System. The Connected System object allows for multiple Integrations to be configured with one system, while hosting the authentication configuration in one place.

Querying vs. Modifying Data

Developers should always be aware of whether the integration will be querying (read-only) or modifying (read/write) data and select the appropriate checkbox for Usage when configuring an Integration object.
- Note: Appian will restrict developers from placing Integrations that modify data in places where duplicate calls can occur.
Unlike other Web Service smart services, Integration objects can be called in SAIL or in process.
Queries via an Integration object can also be used as the source for a service-backed record to create a structured, navigable interface for that data in Appian.

Working with JSON

When building the request body of an Integration object as JSON, you should create CDTs or use dictionary syntax that matches the expected structure to structure the data, and then use the function a!toJson to format the body. This will account for special characters and nulls, and always produce a well-formed structure.
When parsing the response body of an Integration that is expected to be JSON, you should use Automatic Output Parsing (“Convert the JSON Response body to an Appian value”). This will always return your result as structured data in Appian.
- Note: If there are any Date or Date and Time fields expected in the response body, you will need to manually convert these fields from a Text type (e.g. "2018-01-01T12:00:00Z") to a Date or Date and Time type by parsing the string.

Working with XML

When building the request body of an Integration object as XML, you should create CDTs or use dictionary syntax that matches the expected structure to structure the data, and then use the function fn!toxml to format the body. This will account for special characters and nulls, and always produce a well-formed structure.
When parsing the response body of an Integration that is expected to be XML, you should use the option to “Return the raw response body” and then use the function fn!torecord to convert the XML string into the structure of a matching CDT.
- Note: The namespace of the CDT must match the namespace of the XML. If you have the WSDL URL for the XML, you can automatically create CDTs which match the XML structure in your environment by adding it to the Call Web Service Smart Service, and then saving and publishing the process model.

Unsupported Methods or Authentication Configurations

For SOAP-based Web Services that use unsupported or non-standard data structures follow the advice in the Advanced SOAP Web Service Configuration guide.

For Web Services using unsupported authentication methods you may be able to utilize the Advanced Call Web Service or Send HTTP Request plug-ins. If these do not work for your use case you can always write custom function plug-ins to perform the call.

Calling Appian from Other Systems

Other systems can use Web Services to call an Appian Web API to expose Appian expressions such as query data, modify data, or start a process. See the Best Practices for configuring an Appian Web API guide for more information.

Tags: integrations, Architecture

Sizing Hardware for Appian

joel.larin — Mon, 30 Dec 2024 18:41:56 GMT

Current Revision posted to Article by joel.larin on 12/30/2024 6:41:56 PM

Appian's hardware sizing process provides a general estimate of the hardware needed to run your Appian solution.

This estimate is based on several high-level business parameters and is typically used prior to the start of a project. The sizing can be repeated if parameters change significantly due to new business requirements.

The sizing recommendations apply to Production environments only. For non-prod environments we recommend following System Requirements for your Appian version.

NOTE: Hardware sizing is not a replacement for proper performance and load testing.

Requesting a Hardware Sizing

Fill out the Appian CS Hardware Sizing Survey to provide high level estimates of:
- Expected user load
- Process volume
- Data and document size
- Environment configuration
- Service level expectations
Email your Account Executive the completed sizing survey.
Your Account Executive will follow up with you to validate the inputs and provide you with guidance.

Tags: environments, Platform

Sizing Hardware for Appian

joel.larin — Mon, 30 Dec 2024 18:40:53 GMT

Revision 6 posted to Article by joel.larin on 12/30/2024 6:40:53 PM

Appian's hardware sizing process provides a general estimate of the hardware needed to run your Appian solution.

The sizing recommendations apply to Production environments only. For non-prod environments we recommend following System Requirements for your Appian version.

NOTE: Hardware sizing is not a replacement for proper performance and load testing.

Requesting a Hardware Sizing

Fill out the community.appian.com/.../Appian-CS-Hardware-Sizing-Survey-_2800_1_2900_.docx to provide high level estimates of:
- Expected user load
- Process volume
- Data and document size
- Environment configuration
- Service level expectations
Email your Account Executive the completed sizing survey.
Your Account Executive will follow up with you to validate the inputs and provide you with guidance.

Tags: environments, Platform

Sizing Hardware for Appian

joel.larin — Mon, 30 Dec 2024 18:40:28 GMT

Revision 5 posted to Article by joel.larin on 12/30/2024 6:40:28 PM

Appian's hardware sizing process provides a general estimate of the hardware needed to run your Appian solution.

The sizing recommendations apply to Production environments only. For non-prod environments we recommend following System Requirements for your Appian version.

NOTE: Hardware sizing is not a replacement for proper performance and load testing.

Requesting a Hardware Sizing

Fill out the community.appian.com/.../Appian-CS-Hardware-Sizing-Survey-_2800_1_2900_.docx to provide high level estimates of:
- Expected user load
- Process volume
- Data and document size
- Environment configuration
- Service level expectations
Email your Account Executive the completed sizing survey.
Your Account Executive will follow up with you to validate the inputs and provide you with guidance.

Tags: environments, Platform

Performance and Load Testing

joel.larin — Mon, 30 Dec 2024 18:34:47 GMT

Current Revision posted to Article by joel.larin on 12/30/2024 6:34:47 PM

Why Performance Test?

Performance testing can be used to answer critical questions about the application, such as:

Will pages load fast enough to satisfy end users?
Can the application store all of the data that will be collected?
Will performance be consistent over time?
Which areas of my application should I improve?

Answering these types of questions reduces risk, informs current business decisions and assists future planning. Performance testing is needed to determine if the application will perform within specification given a particular situation. It also validates if the resources provided to the application are sufficient for the given volume and data load. The "right" amount of performance testing can only be determined by the project sponsor and stakeholders after considering the importance or visibility of the application, potential revenue loss due to poor performance, and other risk factors.Appian designers should ensure that end user interfaces perform within the specification before they promote the feature to higher environments. If interfaces do not perform adequately during unit testing, they will not improve during performance testing. There are several ways that interface performance can be captured and various troubleshooting techniques. Please see Interface Performance and Debugging for more details.

Process Performance Baseline

When designing process models, designers need to pay attention to the response times between user tasks to ensure appropriate user experience. Similarly to interfaces, processes need to perform appropriately during unit tests, before they can be accepted for performance testing. Performance of individual activities is recorded in logs, and designers can utilize the Appian Health Check to find out if there were any expressions or smart services that could impact end users’ experience. Health Check also provides an HTTP Response Time chart that provides an aggregate view of performance within the environment. These tools should be utilized after every round of functional testing to monitor emerging performance risks. Absence of Health Check should not be a blocker to analyze performance test results. You can still analyze Appian Logs in their tool of choice (Splunk, SolarWinds, Grafana, New Relic, Excel). Additionally, designers can use network monitoring tools built into their browser, to record the exact performance of requests between user clicks during their unit testing.

Performance Testing

Performance testing should be done once the application is in a stable build with the majority of the functionality built out. The app does not have to be complete to get started, but needs to pass the QA/QC cycle, so that performance results are not skewed by application errors. Additionally, performance testing needs to be executed for major releases of the application. Over time, the test will grow to include additional applications and functionality as your platform use evolves.

There are two load factors to consider during performance testing:

Data Load - how much data is in the system during performance testing? This is a frequently overlooked factor but applications need to be tested with a pre-loaded set of data in order to ascertain how it will perform in a realistic situation. Performance testing is often executed with blank databases, which will not be the case 3, 6, 12 months or even at application go-live. Results from such testing will be inaccurate. Please read the Database Volume Testing play for tips on how to load data into your environment.
Load Volume - how many users are in the system creating transactions? When designing your test, you need to find out how many business processes are executed in a given timeframe by how many users. You also need to make sure that all other significant activity in the system is tested, to set up a realistic transaction volume scenario. Tests need to be designed to emulate real user activity, with appropriate pauses between interactions.

More details on methodology, complete with test design templates and helpful tips, can be found under Performance Testing Methodology.

Performance testing should have its own project plan and it should be considered its own agile project. A backlog of performance improvement fixes will start to build with each nightly performance test run. The business should prioritize the improvements based on impact and severity. Promote performance fixes on a nightly basis and rerun the performance test to determine the impact of each change.

Tools

You can execute performance tests using the Appian Locust tool, which uses the open source Locust load testing framework. It provides an easy, programmatic way to develop and execute load and performance tests for Appian. Alternatively, you can use standard web application performance testing tools. These include JMeter and LoadRunner.

Tags: Delivery, testing, Platform