Guide

Fundamentals of Testing in Appian

joel.larin — Thu, 11 Jun 2026 21:52:58 GMT

Current Revision posted to Guide by joel.larin on 6/11/2026 9:52:58 PM

Testing is vital to ensure that only high-quality projects are produced. Throughout the application's lifecycle, testing strategies can be categorized into the following stages:

Before development
During development
Leading up to go-live
During hardening
Deployment

This article will provide an overview of the varied activities and types of tests that can be conducted at each development stage.

Before Development

At the start of the development cycle, the project team should convene to establish a testing strategy. This strategy ensures that project requirements are met, necessary resources are allocated, and potential risks are identified.

User Story Testing Standards

User stories are non-technical descriptions of an application's feature and are central to agile software development. Before development begins, the Appian team and the customer team should agree on standards for testing. A User Story Testing Checklist can be used to test each story. Each user story will be required to pass the criteria set forth in its Definition of Ready, so test cases should be created ahead of time to give the developer a better idea of the requirements.

Performance and Load Testing

These tests assess the application's behavior under varying conditions. Performance testing observes the system during peak usage, while load testing focuses on its response to a large user base. Factors like data size, peak usage, and user count are essential. Before initiating performance testing, it's crucial to:

Identify test data
Establish expected workflow.
Identify different usage scenarios.
Determine the performance test environment.

Additional resources can be found in Performance Testing Methodology.

Automated Testing

Automated testing is a software tool that automates the process of application testing by running a series of test cases. While automating manual end user tests can decrease the time needed for testing, there’s a time and cost involved in creating the tests for the entire application. The project team and stakeholders should meet to determine what types of automated tests will take place based on the time and resources that are available. Some types of automated testing tools are Fitnesse for Appian, Cucumber for Appian, and Appian’s Selenium API.

During Development

Throughout the development sprint, a variety of tests are conducted. Most are performed by the development team, but as the sprint concludes, the client or their QA team should undertake some.

Expression Rule Test Cases

In an expression rule object, test cases can be written and stored to determine if the expected results are being achieved based on certain input. Test cases can be run within the expression rule or through the Manage Test Cases dialog from the Settings menu in the Appian Designer. See Creating Expression Rule Test Cases to learn more.

Unit Testing

Unit testing is for testing individual units or small interconnected functionalities of the application. Typically performed by the developer, test cases are created before development. Objects such as expression rules and decision rules have an expected result, so code is written to test all possible scenarios. More information can be found in Functional Testing - Unit Testing and Creating Expression Rule Test Cases.

An example expression rule that has coverage and error handling tests.

System Integration Testing

After Unit Testing, System integration testing (SIT) is used to assess the overall functionality and interactions between the different components. This testing includes workflows, integrations with outside systems, and database connections.

Peer Testing

During a sprint, peer reviewers (fellow developers from the team) should be utilized to conduct similar tests performed by the developer, as well as to ensure best practices and common design standards are followed. Review the user story testing checklist completed prior to development and use it as a guide for your developer and peer review testing. Consider adopting the AQuAMan framework to automate and speed up some of the peer review process.

User Acceptance Testing

While user acceptance testing (UAT) is typically performed as the final phase in the development sprint and prior to software launch, it should also be done throughout the duration of the project. UAT is designed to make sure an application meets the needs of the business, is free of bugs, and functions as intended. See User Acceptance Testing Overview for more.

Regression Testing

Regression testing is used to ensure that any changes or updates in the software will not negatively affect the working functionality of the application amidst the new changes.

Exploratory Testing

Exploratory testing is used to identify potential edge cases, i.e. problems that occur only under unique, rare conditions. This type of testing is performed by testers themselves rather than automated scripts. Be sure to incorporate exploratory testing as it's useful for catching bugs that might otherwise go undetected.

Leading Up to Go Live

Prior to the Go Live, stringent user acceptance testing should be performed at a level of granularity that is appropriate for the scope of work.

During Hardening

During Hardening, the team’s time is focused on full end-to-end testing, catching and resolving bugs, and fine tuning application performance. While most major bugs and issues should have already been resolved in prior testing phases, hardening provides an opportunity to catch more minor flaws and UX adjustments, thereby mitigating risk and improving overall confidence in the production release.

End to End Testing

In end to end testing, the focus is on the entire system’s functionality. It’s purpose is to ensure the flow of data is maintained and the software works as intended in all environments. End to end testing can be performed/assissted by automated testing tools like Fitnesse for Appian.

Exploratory Testing

It's a good idea to again use exploratory testing during the hardening phase, as edge cases can be hard to find using automated tools.

Deployment

Testing during the deployment stage allows the team to evaluate the functionality of the application in the exact environment where it needs to function.

Systems Integration Testing

After deployment, SIT is again performed to evaluate the behavior of the entire integrated system and to make sure that all connections have been maintained.

Unit Testing

When inspection occurs during direct deployment, Appian will check the package for any failing test cases. Review and rerun test cases until the issues are resolved. See Functional Testing - Unit Testing for more information.

Regression Testing

After work completes on development, regression testing should be performed by the QA team to ensure that all components are still functional and work as intended.

Health Check

Health Check is a process that provides insights into an application. It can identify services and nodes that pose a high risk to the performance of the application, check to make sure that best practices are being followed, and provide graphs detailing historical trends in the environment. See the Health Check documentation for more.

Testing is an important step in the development of any application. Tests need to be planned and executed during every stage of software development. By having a proper test plan, you can identify bugs, errors, and missing requirements, which will guarantee the quality of the application.

Downloadables

This one-pager identifies critical testing strategies that should be embedded in every Appian delivery team and recommends others that are dependent upon the client and solution being developed.

community.appian.com/.../Appian_5F00_testing_5F00_one_5F00_pager.pdf

Tags: testing, Architecture

Integrating with Amazon Machine Learning

joel.larin — Thu, 11 Jun 2026 21:52:43 GMT

Current Revision posted to Guide by joel.larin on 6/11/2026 9:52:43 PM

Note: Amazon ML is no longer available to new Amazon customers

This article provides information about integrating with Amazon Machine Learning. If you are unfamiliar with machine learning, it is recommended that you read the Machine Learning Overview article for information about the technology, different model types and training data guidance.

Amazon offers a plethora of services that all fall under its machine learning arm from translation services (Amazon Translate) to video recognition (Amazon DeepLens). Appian can integrate with all of these services; however, this article solely focuses on the Amazon Machine Learning service through the use of the Appian AI Designer. Furthermore, there are many other machine learning offerings available including Google Cloud and Microsoft Azure. Appian is integration agnostic and has the ability to connect with all of them.

Amazon Machine Learning Models

Amazon Machine Learning (AML) supports three different type of ML models. The type of model that Amazon will build depends on the type of target attribute that you want to predict.

Model	Prediction Type	Performance Metric
Regression	Predicts a numeric value	Root Mean Square Error (RMSE)
Binary Classification	Predicts binary values (ex. true or false)	Area Under the Curve (AUC)
Multiclass Classification	Predicts values that belong to a limited, predefined set of permissible values	F1 Score

Creating Amazon ML Models in Appian

The following steps outline how to create a model using the Appian AI Designer shared component. It is possible to create models directly in the AML admin console. It also possible to interact with models in Appian that already exist or have not been created using the Appian AI Designer (for more information on making predictions see next section).

Create an Amazon developer account and an Amazon S3 bucket to store the data you will use to create your model. A credit card is required and you will be charged to create models and make predictions, but costs are relatively insignificant (see AML pricing).
Download Appian AI Designer from shared components and follow the deployment instructions.
1. Note: you will need to have Appian automatically create the database tables by manually publishing the data store after the application import.

Collect data used to create the model and format into csv where one row consists of an observation with multiple features (or attributes) and one target attribute. The more observations (rows in the csv) included, the better the model. Below is a sample set of data for banking customers where the first 9 columns represent features that will be used by the model to recognize patterns and relationships while the last column (y) is the binary target value the model will try to predict. In this case y represents if the banking customer decided to take an offer pitched over the phone.

age	job	marital	education	default	housing	contact	duration	day_of_w	y
44	blue-collar	married	basic.4y	0	1	cellular	210	thu	0
53	technical	married	unknown	1	0	telephone	180	fri	1
28	management	single	university.degree	0	1	cellular	465	mon	1
39	services	divorced	high.school	0	1	cellular	180	wed	0

Navigate to: https://<your.server>/suite/sites/aml and follow the sites wizard to create a new model.
1. On the first tab you can select the S3 bucket created earlier.
2. If you do not plan on using Amazon’s feature transformation formulas than ensure that any data manipulation has done before formatting the data into a csv. See feature transformation below for more information.

Making Predictions

Once a model is created you can make batch predictions or individual real-time predictions. There are two main ways to make real time predictions within Appian: you can use either the shared component function AML_getRealtimePrediction or you can use the connected system object in Appian versions 18.2 or later. The AML_getRealtimePrediction function takes in a model ID and two parallel arrays that hold attribute names and attribute values. If using this function it is recommended to create a mapping rule that takes in a CDT and converts the CDT values into a text array to be passed into AML_getRealtimePrediction. Before even creating a connected system or creating a rule to call the API you can test out real time predictions from the AML admin console or from the machine learning model record in the Appian AI designer site. It's recommended to test out the predictions and evaluate the model (more below) before deciding to move forward with an initial model.

Evaluating and Adjusting Model Performance

Whenever a new model is created there are four objects created in the AML Admin Console: One training data source, one evaluation data source, one model, and one evaluation object. As discussed above, Amazon uses different metrics to quantify performance. In addition, Amazon provides a different performance visualization for each model. To access the performance metric and visualizations navigate to the admin console and select the evaluation object. For binary classification models you are able to adjust output using the dual histogram visualization (pictured below) by raising or lowering the score threshold that is defaulted to 0.5. For example if you would like to automate a process by auto approving likely true values you may want to raise the score threshold to a value closer to 1 in order to limit the false positives (raising the score threshold has the effect of increasing the probability needed for the model to predict a value as true). Inversely, if you would like to flag values that are likely false for further review you may want to lower the score threshold in order to limit the false negatives.

Another way to evaluate the model is to take a look at how each feature correlates to the target value. Some values have more of an impact of the predicted outcomes and this is quantified by Amazon (to view these values navigate to either of the data sources in the AML admin console). It is generally a best practice to include as many relevant features as possible in your data set, but noise introduced by including too many variables with little predictive power may negatively impact your models performance.

Best Practices

Retraining Models

Retraining is the process of providing new data to models in attempt keep your model accurate with the drift of actual outcome distribution over time. Like most application development, implementing a machine learning model is not a one time activity; it is best practice to continuously monitor your model and retrain it if new observations begin to deviate from the original training data distributions.
In order to retrain a model in Amazon you will need to create a completely new model with your updated data set. Be sure to avoid hard coding model Ids in your Appian applications so that updating your applications after retraining models will only require updating a single object such as a constant or connected system.

Feature Transformation

A key characteristic of good training data is that it is provided in a way that is optimized for learning and generalization. The process of putting together the data in this optimal format is known in the industry as feature transformation.
Feature transformation can be performed on all types of data (numeric, text, boolean). A simple example of feature transformation is converting all null numeric values to 0, but can also include more complex formulas for the purpose of normalizing data or discovering non-linearity in the variables distribution.
Feature transformation can take place prior to uploading data in Amazon or you can use built-in transformation recipes within the Amazon machine learning console. Regardless of the method used, the process should be repeatable such that models can be recreated or re-trained easily.

Splitting Data

In order to test the accuracy of ML models a percentage of the data provided to Amazon is set aside for evaluation. By default Amazon splits the data such that 70% of it is used to train the model while 30% is used to evaluate it. The split percentage can be altered when creating the model.
It is important to split the input data such that there is a random distribution of observations between the training and evaluation data sources. If the data for either data source is skewed towards a certain target value the ML model could be skewed and the evaluation model may not be indicative of true performance.

Shuffling Data

In Amazon ML, you must shuffle your training data. Shuffling mixes up the order of your data so that the SGD algorithm doesn't encounter one type of data for too many observations in succession.
When creating a model via the admin console or the Appian AI Designer shared component wizard, you can indicate if you would like Amazon to shuffle your data or if you have already shuffled it.

See Also

Websites:

AML Developer Guide

Tags: integrations, Architecture

Leverage JMeter in Appian Load Testing

joel.larin — Thu, 11 Jun 2026 21:52:24 GMT

Current Revision posted to Guide by joel.larin on 6/11/2026 9:52:24 PM

Apache JMeter is an open source Java performance testing tool which can be used to simulate user load on a web application. This guide explains how to use JMeter to implement and run test scripts for Appian applications as part of the Appian Performance Testing Methodology. It is important to note that test script implementation and execution are only two steps in the methodology. A test plan should be defined before starting implementation.

Recording New Scenarios

JMeter scripts are created by recording activity in the browser or mobile app using an HTTP(S) Test Script Recorder. Recording and parameterizing test scenarios is the primary task of test implementation.

JMeter for Appian

It is highly recommended to start by installing the JMeter for Appian utility. This is an add-on for JMeter's Test Script Recorder that automatically extracts standard dynamic values that are passed back and forth when a user interacts with Appian. This saves a lot of time when parameterizing your recorded scripts.

JMeter Properties

The following properties allow cookies to be stored as variables which allow the JMeter scripts to reference client cookies. Ensure they are set to the below values in the user.properties file.

CookieManager.save.cookies=true
CookieManager.allow_variable_cookies=true

Pre-Recording Proxy Configurations

Before recording, the JMeter Test Script Recorder must be configured. Several additional configuration elements will make the recorded requests easier to convert into repeatable test scenarios.

Update the URL inclusion regular expression pattern of the HTTP(S) Test Script Recorder to match the domain name or IP of the performance test environment (eg: .*mysite\.com.* - note the escaped periods using \.)
Update the HTTP Request Defaults to set the fully-qualified domain name or IP of the performance test environment (eg: mysite.com) and scheme (http or https). If the Server Name is left blank in all subsequent HTTP recorders, this will be inherited from the default values which makes it very easy to point the scripts to a different Appian environment.
Start the HTTP(S) Test Script Recorder
Configure the browser or mobile network proxy settings to point to the JMeter proxy machine and port
- Browser
  - Open up browser settings and search for "Proxy"
- Mobile devices
  - The mobile device must have access to the machine running the JMeter proxy (eg: same wireless network, no firewall restrictions)
  - Additional steps are needed when using SSL/HTTPS sites with mobile devices
  - iOS: Settings->Wi-Fi->(connected network)->HTTP Proxy->Manual
  - Android: Not recommended due to inconsistent support for proxies and custom SSL certificates (if using SSL/HTTPS)

Considerations for Authentication

Once a client authenticates with Appian, a cookie with the name appianCsrfToken is created. Appian requires this token to be passed in as the value of the X-APPIAN-CSRF-TOKEN header during subsequent requests. In order to access the cookie’s value, set the value of this header to ${COOKIE___appianCsrfToken} in JMeter. This is automatically done when leveraging the JMeter for Appian utility. If this token is not correctly passed, Appian will return back a 401 - Unauthorized.

Working With SAIL Interfaces

When scripting user interactions on a SAIL form, certain dynamic values need to be extracted from the previous responses and provided as part of the next request:

cID - The cID of the component being interacted with
saveInto - The saveInto identifier of the component being interacted with
context - An identifier that references the SAIL context stored in the application server
uuid - The unique identifier of the interface instance

Below is an example of a request modeling a user clicking a button widget with all dynamic values parameterized. This is automatically done when leveraging the JMeter for Appian utility.

Working With Tasks

When interacting with an Appian task, the HTTP request path will need to reference its opaque task identifier as outlined below:

/suite/rest/a/task/latest/${OPAQUE_TASK_ID}/form

This can be extracted from the previous HTTP request and parameterized to allow for performance testing playback.

Special Handling for File Uploads

The JMeter proxy server does not capture uploaded files from the HTTP request. Instead it references the file directly from the local filesystem using the path specified in the request. Since most browsers submit just the name of the file (not the full path) the proxy usually can’t find the file to send on to the server and the request fails.

In order to support file uploads when using JMeter, the uploaded file must be located in the directory where JMeter was launched. If JMeter was launched with ApacheJMeter.jar then the uploaded file should be in the same directory as this file. Move or copy files that will be part of the test script to the JMeter launch directory, then select them from that location when choosing the file to upload in the browser.

When recording a file upload, one request will be created to upload the file to the Appian server and another will be created to place the uploaded file in the interface’s appropriate file upload component. The file ID provided in the response of the first request will need to be extracted and referenced in the second request. This is automatically done when leveraging the JMeter for Appian utility.

More information on handling mobile uploads can be found here.

Running Recorded Scripts

Using JMeter GUI

When tests aren’t working or produce unexpected results, run a quick smoke test. While GUI mode is not recommended for full-load test runs (due to performance concerns) the Summary Report and View Results Tree provide an extremely useful visual tool when diagnosing test problems.

The Summary Report listener aggregates all samples for a given step and can be used to identify steps with a high error rate or with abnormal response times.

The View Results Tree listener displays the request and response details for each individual sample which allows you to drill down to the root cause of any errors.

Command Line Configuration

Full performance tests (as opposed to test script development or verification) should be run using Command Line mode (CLI mode).

Parameters are set as program arguments using the syntax -J<name of parameter>=<value>. For example, the following command specifies a duration of 1 hour (3600 seconds), a rampup of 1 minute (60 seconds), and an iteration delay of 1 minute (60000 milliseconds). The test name, user load multiplier, think time delay, and think time deviation will use the values saved in the test script.
```
c:\apache-jmeter-2.9\bin\jmeter -t "RefApp Test Plan.jmx" -n -JTEST_DURATION=3600 -JRAMPUP_PERIOD=60 -JITERATION_DELAY=60000
```

To run the same test with 10 times the original user load and rampup over 10 minutes, change the values for RAMPUP_PERIOD and USER_MULTIPLIER:

c:\apache-jmeter-2.9\bin\jmeter -t "RefApp Test Plan.jmx" -n -JTEST_DURATION=3600 -JRAMPUP_PERIOD=600 -JUSER_MULTIPLIER=10 -JITERATION_DELAY=60000

Common Problems

New test scenarios not captured

If no activity appears in the View Tree Results listener under the HTTP(S) Test Script Recorder then requests are not being sent to JMeter. Correct the proxy settings in the browser/mobile device.

If requests appear in the View Tree Results listener but are not captured in the Recording Controller then the URL inclusion regular expression is not matching the target site URL. Correct the regular expression in the URL Patterns to Include settings of the HTTP(S) Test Script Recorder.

High Error %

JMeter transactions can fail for several reasons:

Server returned an error response code (eg: 500 Server Error, 404 Not Found)
Server response timed out
Response assertion failed (eg: expected “Submit Details” but got “View Details”)

Errors may indicate a user-facing defect in the application or a problem with the test design. In other cases an error may be expected depending on conditions (eg: empty paging grids return 404 status codes).

The JMeter Summary Report listener and the JMeter Analysis Worksheet both track the error rate for each transaction.

Too few/too many requests

The test design and test parameters should define a relatively consistent number of requests in any given period of time. If the results deviate significantly from the expected output it is a good sign that something went wrong with the test. Double check the test parameters and consider running a GUI smoke test to find the source of the problem.

Uneven request distribution over the test duration

The design of the example script is intended to simulate a random but relatively uniform load over the course of the test period. While some periods of higher than expected load are part of a realistic test, a continuous series of spikes and lulls is unlikely to provide realistic performance results.

In order to visualize the request distribution, plot requests vs time and look for repeating patterns of high and low load. A longer rampup time may help eliminate uneven distribution.

Even distribution

Uneven distribution

Not enough rampup time

The JMeter Analysis Worksheet automatically filters out results from the rampup period but insufficient rampup time can cause some performance impact to carry over into the test period. The minimum safe rampup time will depend on the speed of the client machine, network, and server. In general, make sure that the rampup time (in seconds) is at least as high as the number of simulated users in the test (eg: a 100 user test should use a rampup time of at least 100 seconds).

Cascading errors/unexpected process flow

Since JMeter simply sends a sequence of scripted requests to the server its ability to adapt to unexpected responses is limited and often results in a series of cascading errors. For example, if a form submission response does not contain the activity id of the next chained form because of an error, the next request will also fail.

These errors are usually caused by changes in the application being tested. Response assertions can be used to validate responses and identify these situations more clearly. Depending on how significant the change is the affected steps or the entire scenario may need to be re-recorded.

Special Considerations for Mobile

Uploading Files from Mobile Devices

As described earlier, file uploads require special steps when using the JMeter recorder. The workaround for uploading files is slightly more complex when using a mobile device since the file is on a different device and cannot be easily moved into the JMeter launch directory.

Attempt to upload a file from the mobile form (take a photo, choose a photo, etc)
The request will be captured by JMeter, but the file upload field will display an error on the mobile form
In JMeter, note the name of the file in the newly captured request
Copy the file from the mobile device to the JMeter proxy machine, or use a placeholder file if the actual content of the file is not important
Move the file to the JMeter launch directory and rename it to match the name in the captured request
Submit the mobile form to retry the failed upload
1. The upload will succeed and the form will be submitted
2. JMeter will record a second file upload request immediately before the form submission request
Remove the second file upload request from the recorded scenario in JMeter (the original request will work when the script is replayed)

Recording SSL/HTTPS Traffic from Mobile Devices

The JMeter proxy server uses a self-signed SSL certificate to record HTTPS requests. See the JMeter documentation for details.

Most browsers will show a warning message that can be safely ignored in order to proceed with test recording. However, the Appian mobile app doesn’t have the same warning/override option as a browser and automatically rejects invalid SSL certificates.

In order to record test scripts with HTTPS sites, a custom proxy certificate must be generated and installed on the JMeter proxy server and the mobile device. This is recommended only for users familiar with SSL/HTTPS and network concepts.

iOS

These instructions are for Windows users but apply to any OS platform. The Java JDK 7+ must be installed.

Generate a custom SSL certificate using keytool
1. Open a command window and switch to the <jmeter>/bin directory
2. Rename proxyserver.jks to proxyserver.jks.bak
3. Run the following command:
```
keytool -genkey -keyalg RSA -alias selfsigned -keystore proxyserver.jks -storepass password -validity 999 -keysize 2048 -ext bc
```
  - Note: The -ext parameter was added in Java 7 and is required to create a trusted certificate. This command can be run on any machine with Java 7+ and the resulting .jks file will still work with earlier Java versions.
4. Instead of providing a first and last name, enter the URL of the Appian test environment (eg: www.mysite.com)
  - Use a wildcard to match multiple sites (eg: *.mysite.com)
5. Answer the remaining questions to generate a self-signed certificate in proxyserver.jks
Install the certificate on the JMeter proxy server
1. The previous command automatically generates the certificate in the default location
2. Start the JMeter proxy server
3. Access the test site in a browser that uses the JMeter proxy
4. Confirm that the browser shows a warning with the new certificate details
Install the certificate on the mobile device
1. Run the following command:
```
keytool -exportcert -keystore proxyserver.jks -alias selfsigned > proxyserver.crt
```
2. Email proxyserver.crt to your iOS device (or transfer it via another method)
3. Open proxyserver.crt and install it as a trusted root profile on the device
4. Confirm that the profile is listed and trusted in Settings->General->Profiles
The Appian app should now be able to connect to an HTTPS site while using the JMeter proxy server

Note: If the URL of the test environment changes the generated certificate may no longer be valid. If this happens a new certificate will be needed.

Tags: testing, Architecture

Automated Testing With FitNesse for Appian

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

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

Please be advised that this package has moved to a new open-source repository, as future updates on the App Market will be discontinued. We encourage all users to switch to the new repository to gain the ability to contribute, receive immediate access to bug fixes and new functionality, and improve communication with other users and maintainers via GitLab issues.

FitNesse for Appian is a client side tool, built on top of FitNesse, that makes it easy to create automated tests on the Appian platform. This tool allows you to create test scripts in a easy to read wiki language that will be run by the system to interact with an Appian application as a human user.

FitNesse for Appian provides an Appian-specific wiki language within FitNesse that maps directly to actions that can be performed in Appian, such as:

Navigating the interface (News, Tasks, Records, Reports, Actions, Sites)
Starting actions and completing tasks
Validating content on record views or in news events
And much more... the complete list is available directly within the tool!

For more information about testing and development best practices when using FitNesse for Appian, visit the FitNesse for Appian Best Practices guide.

Requirements

Appian 22.2 and above
Java Runtime Environment 11
Chrome or Firefox browsers
If using Chrome, we recommend using Chrome For Testing for a more consistent testing experience.

Setup

The zip file for the tool can be downloaded from the App Market Public Listings.

Unzip the contents into your root directory or preferred location (e.g. C:\)
In a terminal window navigate to the folder extracted from the zip file (e.g. C:\fitnesse-for-appian). We will refer to this directory as TESTING_HOME throughout this documentation
1. For PC, main commands will be:
  1. dir: used to show contents of current directory (folder)
  2. cd: used to change directory (open a folder), e.g. cd Documents would open the Documents folder. cd .. would go to the parent folder of current folder.
2. For Mac/Linux,
  1. ls: used to show contents of a directory (folder)
  2. cd: used to change directory (open a folder), e.g. cd Documents would open the Documents folder. cd .. would go to the parent folder of current folder.
Open the "custom.properties" file located in TESTING_HOME/configs and change:
1. automated.testing.home to be TESTING_HOME (e.g. C:\FitNesseForAppian)
2. download.directory to be a folder of your choosing
3. chrome.driver.home to be TESTING_HOME/lib/drivers/chromedriver(.exe if using windows, -mac if using a mac, -linux if using UNIX)
4. firefox.driver.home to be TESTING_HOME/lib/drivers/geckodriver(.exe if using windows, -mac if using a mac, -linux64 if using UNIX)
Run start.bat if using windows, start-mac.sh for Mac, and start-unix.sh for UNIX to install and run FitNesse for Appian. Installation should take around 30 seconds and is complete when you see the message "Starting FitNesse on port: 8980". To stop FitNesse for Appian, invoke Ctrl+C in the terminal.

Running your first FitNesse test

Start FitNesse if it isn't already running by running start.bat/start-mac.sh/start-unix.sh depending on your system
Navigate to http://localhost:8980/FitNesseForAppian.Examples.TestExample
Follow the configuration instructions marked by "Please follow the directions below to execute the test"
Click Test at the top of the page

Developing custom tests

To try out the tool further, use the Appian application included in the combined files download (Automated Testing - 1x.x.zip) and import it into your corresponding version of Appian environment.

Navigate to the FitNesseForAppian Cheatsheet and make use of the supported methods to write your own test suite to run against the sample application! Be sure you are using methods for the environment you are testing. For example, if testing sites, use navigation methods that come from the "Sites Methods" scenario. Using methods from a different environment has the potential to break in future releases.

An example test suite run could look like this:

By default, the tool collects usage metrics for analytics purposes. Set collect.metrics=false in the "metrics.properties" file to opt-out of metrics collection.

Features

Multiple browser support

Chrome (v64-66)
Firefox (v53-62)

Benefits

Test your Appian application within minutes of downloading the tool
Methods created specifically to operate within Appian applications and Tempo
Test scripts do not need to be updated for upgrades to supported Appian versions
Test scripts are written in a wiki language that is very easy to read and synthesize
Appian design knowledge is not required to create test scripts
Common case scenarios can be created for reusability throughout test suites
Isolate test steps into scenarios to perform Spec by Example tests
Test scripts are easily updated for new UI changes to a form or interface

Release Notes

March 2025 - Release 25.1

Enhancements
- Added support for defining and using custom locales. Use create appian locale | PATH TO File. This method must be called after setting the version.
  - File must be JSON file with the format: { "dateFormats": [ { "label": "dateFormat", "value": <FORMAT_STRING> }, { "label": "dateDisplayFormat", "value": <FORMAT_STRING> }, { "label": "timeFormat", "value": <FORMAT_STRING> }, { "label": "timeDisplayFormat", "value": <FORMAT_STRING> }, { "label": "datetimeFormat", "value": <FORMAT_STRING> }, { "label": "datetimeDisplayFormat","value": <FORMAT_STRING> } ], "labels": [ { "label": "acceptButton", "value": "Accept" } ], "locale": <LOCALE_CODE> }
Bug Fixes
- Fixed clickOnRecordRelatedAction to function correctly when the Record Summary page contains more than three action items.

August 2024 - Release 24.3

Enhancements
- Added built-in retry to click operation in case of element not interactable exception.
- Updated the milestone locator.

June 2024 - Release 24.2

Enhancements
- Updated locator for site menu links
- Created method which supports clicking on text within an interface. This is particularly useful for nested cards such as tab layouts, but can also be used as a fallback when existing methods don't work. This method is available for all Appian versions.
- Click operation on Card layout will be performed on the left side of the element instead of the right. We're not expecting any impact on existing test cases.

March 2024 - Release 24.1

Enhancements
- Support for Appian version 24.1
- Adds support for collapsing/opening sidebars
- ClickOnCard updated to support clicking on cards with complex content. For example, the method can now click on cards that have a component nested in multiple layouts within the card

November 2023 - Release 23.4

NOTE: Project has been updated to require Java 11 JRE
Enhancements
- Support for Appian version 23.4
- Add support for the side navigation menu in sites
- Add support for downloading charts
- Add support for buttons configured with custom colors
Bug Fixes
- Honor the download directory given in custom.properties for Remote Drivers
- Update dropdowns for versions greater than 23.3 to ignore the aria-checked value
- Fixed Populate Record Type Data Range User Filter method

August 2023 - Release 23.3

Enhancements
- Supports Appian version 23.3
- Added functionality to interact with new site group headers
- Updated to Selenium 4.11.0
- Add support for Date Range user filters in Record Types
- Update checkboxes to support CARD style for 23.3 and later Appian versions

June 2023 - Release 23.2.1

NOTE: Updates to site navigation in the 23.2 product breaks the use of the "click on menu" method in site environments. "click on menu", and other navigation methods from Tempo, are guaranteed to work only in Tempo environments. Use the "click on site page" method instead
Bug Fixes
- Update pickers to recognize selections with links (e.g. Record Pickers)

June 2023 - Release 23.2

Enhancements
- Supports Appian version 23.2
- NOTE: Updates to site navigation in the 23.2 product breaks the use of the "click on menu" method in site environments. "click on menu", and other navigation methods from Tempo, are guaranteed to work only in Tempo environments. Use the "click on site page" method instead

May 2023 - Release 23.1.2

Bug Fixes
- Fixes an issue where Dropdowns with Search were not working
- Fixes an Issue where verifyText did not work on multi-node components

February 2023 - Release 23.1

Enhancements
- Supports Appian version 23.1
- Updated locator for Dropdown class
Bug Fixes
- Update CVEs
- Update scripts (start.bat, start-mac.sh, start-unix.sh, runFitNesseTest.sh) toreference the new fitnesse-20221219-standalone.jar

August 2022 - Release 22.3

FitNesse for Appian is released and supported
Removed support for 20.3

November 2021 - Release 21.4

Enhancements
- Support new card choice components
Bug Fixes
- Update CVEs

August 2021 - Release 21.3

Bug Fixes
- Fix bug for radio button card
- Fix bug for date picker

June 2021 - Release 21.2

Enhancements
- Support new SectionLayout
- Upgrade Selenium Server to 3.141.59
Bug Fixes
- Fix bug for radio button card
- Fix bug for icon link alt text

February 2021 - Release 21.1

Enhancements
- Supports Appian version 21.1

November 2020 - Release 20.4

Enhancements
- Support Chrome capabilities
- Update FitNesse version to 20200501
- NEW METHOD: Support Stamp Field
- NEW METHOD: Support Tag field
- NEW METHOD: Support signature field
- NEW METHOD: Support record action field
Bug Fixes
- Fix grid row count bug when there is no paging
- Fix getGridColumnRowValue when the grid cell is a button
- Fix clear picker bug when there are multiple selections
- Fix capturing an empty rich text field

September 2020 - Release 20.3

Enhancements
- NEW METHOD: Populates the search box in a dropdown with some text
Bug Fixes
- Fixed a bug for custom login submit button

August 2020 - Release 20.2.1

Bug fixes
- Fixed a bug regarding clicking on card layouts

July 2020 - Release 20.2

Bug fixes
- Fix bug with milestone click
- Fix toggle box visibility on related action pop up

Apr 2020 - Release 20.1

Enhancements
- NEW METHOD: click on bar chart
- NEW METHOD: click on menu widget
- NEW METHOD: click on button with tooltip
- NEW METHOD: verify confirmation dialog header
- NEW METHOD: verify confirmation dialog message
- NEW METHOD: Verify a field is not blank
- NEW METHOD: click on document image link
- NEW METHOD: clear search field in record
Bug fixes
- Remove pie chart hover for fragility and also make it the page scroll before hovering for firefox
- Clicking on standalone icons by making the xpath less specific
- Fixed closing social task bug

January 2020 - Release 19.4.1

Enhancements
- NEW METHOD: star and unstar action with action name
- NEW METHOD: click on icon link with alt text
Bug fixes
- Fixed issues for dropdowns with many options

November 2019 - Release 19.4

Enhancements
- NEW METHOD: verify button with label is enabled
- NEW METHOD: verify button with label is disabled
- NEW METHOD: verify link containing text is not present
- NEW METHOD: verify a box with given label is present
- NEW METHOD: verify a box with given label is not present
- NEW METHOD: verify a section with given label is present
- NEW METHOD: verify a section with given label is not present
- NEW METHOD: verify a card with given accessibility text is present
- NEW METHOD: verify a card with given accessibility text is not present
- NEW METHOD: verify if text is not present anywhere in the user interface
Bug fixes
- Fixed populate first column in a grid when rowheader is set to 1

September 2019 - Release 19.3.1

Enhancements
- Added additional logging for site page navigation

Bug fixes
- Fixed verify text present for text with apostrophe

Sep 2019 - Release 19.3

Enhancements
- Support gauge field
- Support locating field using placeholder, instructions or tooltip
- NEW METHOD: get gauge field GAUGE_FIELD or GAUGE_FIELD[INDEX] percentage
- NEW METHOD: verify gauge field GAUGE_FIELD or GAUGE_FIELD[INDEX] percentage is PERCENTAGE
- NEW METHOD: populate field with placeholder PLACEHOLDER with VALUE(S)
- NEW METHOD: populate field with instructions INSTRUCTIONS with VALUE(S)
- NEW METHOD: populate field with tooltip TOOLTIP with VALUE(S)
- NEW METHOD: get field with placeholder PLACEHOLDER value
- NEW METHOD: get field with instructions INSTRUCTIONS value
- NEW METHOD: get field with tooltip TOOLTIP value
- NEW METHOD: verify field with placeholder PLACEHOLDER contains VALUE(S)
- NEW METHOD: verify field with instructions INSTRUCTIONS contains VALUE(S)
- NEW METHOD: verify field with tooltip TOOLTIP contains VALUE(S)

June 2019 - Release 19.2

Bug fixes
- Support sending news post without participants

May 2019 - Release 19.1.3

Bug fixes
- Fixed the bug that users can not click on menu tabs on Appian 19.1
- Fixed the bug on Read Only field "contains"
- Fixed the bug on sending news post on Appian 19.1

April 2019 - Release 19.1.2

Enhancements
- Support Wait For Progress
- Support Click on X and Y coordinates on monitor
Bug fixes
- Fixed the bug that box layout toggle only acts on the first box

March 2019 - Release 19.1.1

Bug fixes
- Fixed error popup caused by loading Automation Extension

February 2019 - Release 19.1

Enhancements
- Support Masked Barcode
- Support Vertical Milestone
Bug fixes
- Fixed login with terms for 17.2

January 2019 - Release 18.4.4

Enhancements
- NEW METHOD: populate field with partially matching picker field suggestion
- NEW METHOD: login into URL with username
- NEW METHOD: login into URL with role
- NEW METHOD: wait for seconds
- NEW METHOD: wait for minutes
- NEW METHOD: wait for working

January 2019 - Release 18.4.3

Enhancements
- Add capability to run tests on remote web drivers
Bug fixes
- Fixed milestone step verification
- Fixed section containing validation message verification

December 2018 - Release 18.4.2

Enhancements
- NEW METHOD: populate grid column row with partially matching picker field suggestion
- Other minor enhancements

November 2018 - Release 18.4.1

Enhancements
- Documentation overhaul
- Improved out of the box examples
- Updated information about supported Appian versions

October 2018 - Release 18.4

Enhancements
- NEW METHOD: open settings menu
- NEW METHOD: open user profile
- NEW METHOD: use discoverability to navigate to
- NEW METHOD: close social task
- NEW METHOD: verify task feed containing text is not present
- Added usage metrics and corresponding metrics.properties file
Bug Fixes
- Fixed login with terms

August 2018 - Release 18.3.1

Enhancements
- Added new methods for hovering and clicking on profile links and circles in news posts
Bug fixes
- Fixed NoClassDefFoundError for TempoEncryptedTextField introduced in 18.3

August 2018 - Release 18.3

Enhancements
- NEW METHOD: create a news post
- NEW METHOD: send kudos
- NEW METHOD: send messages
- NEW METHOD: send tasks
- NEW METHOD: sort tasks
- NEW METHOD: star a news feed item
- NEW METHOD: filter news feed
- NEW METHOD: navigate to link in news post
- NEW METHOD: generic assertion that text is present
Bug Fixes
- Fixed bug with MilestoneField pre-18.2
- Added WebContentField to 18.1

May 2018 - Release 18.2.1

Enhancements
- Auto login to previously set URL
- Milestones in side by side layout
- Card click identified by link name index
- NEW METHOD: verify video (not) present
- NEW METHOD: verify web content (not) present
- Updated test app for 18.2
Bug fixes
- User pickers not selecting correct field value
- Card click not working in Firefox

May 2018 - Release 18.2

Enhancements
- Added support for 18.2
- NEW METHOD: click on card
- Updated select grid method to account for the row highlight selection style
- Added test app for 18.2
Bug fixes
- Fixed fragility of file upload

March 2018 - Release 18.1.4

Enhancements
- Added Support for finding grid indices
- Added the ability to delete documents downloaded by Fitnesse

February 2018 - Release 18.1.3

Bug fixes
- Updated mac and linux scripts shebang to /bin/sh

February 2018 - Release 18.1.2

Bug fixes
- Fixed Windows start script to run FitNesse successfully
- Fixed the example page and default fixture to use TempoFixture instead of SitesFixture

January 2018 - Release 18.1.1

Enhancements
- Updated 16.3 Test Zip
Bug fixes
- Fixed issue with navigating to /logout URL
- Fixed Multiselect dropdown on 16.3
- Fixed Record filter clearing on 16.3

January 2018 - Release 18.1

Enhancements
- Added support for 18.1
- Added test app for 17.3 and 18.1

January 2018 - Release 17.4.1

Enhancements
- Add ability to accept Tasks
- Add ability to populate Record Type user filter
- Add ability to download files
- Make LinkField capturable
- Added advanced functionality to adjust dates, including setting dates in the past
- If url contains "/suite", remove anything after it to prevent navigation failure.
Bug fixes
- Updated chromedriver to version 2.33
- Updated startup scripts to pass FitNesseRoot properly
- Always logout before login in case a previous test failed and didn't logout
- Made Firefox webdrivers executable
- Fix BarcodeField not working in 17.1+

November 2017 - Release 17.4

Enhancement
- Change FitNesse usernames
- Allow FitNesse tests to hit an arbitrary endpoint through an environment variable
Bug fixes
- Mac Firefox date and dateTime field tests no longer throw an null character
- Dropdown tests does not read duplicate values

October 2017 - Release 17.3.2

Enhancements
- Updated test application to run initialize on import
Bug fixes
- Checkboxes that are too short are not checked

October 2017 - Release 17.3.1

Enhancements
- Updated Test App to create users
- Documentation tweaks/ Readme tweaks
Bug fixes
- Allowed login for internationalized pages
- Fixed an issue preventing searching in record list view
- Changed the way the start-unix script was sourced

September 2017 - Release 17.3

Enhancements
- Supports Appian version 17.3
- Ability to configure custom login page
- Updated the following components to be compatible with the latest Appian Hotfix Package for 17.1 (G), and 17.2 (D):
  - Paging Grid
  - Editable Grid
- Scripts now recognize new loading bar and wait for it to be done before continuing
- Added shell scripts and drivers for F4A on Mac and Linux
Bug fixes
- Browser is maximized by default which ensures the "Sign Out" button is always visibleNote: Previously tests could hang waiting to logout if the browser window was within a specific size range where the "Sign Out" button got hidden

Tags: testing, Architecture

Automated Testing

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

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

Automated testing reduces the amount of manual testing necessary in an Appian application and reduces risk at each stage of the application development lifecycle. Automated testing can be used throughout the Appian application development lifecycle to:

Test new rules created within an Appian application such as conditional fields, complex business logic, or validations
Complete functional testing to ensure all requirements are verified and validated
Regression test the application to ensure that existing functionality is not affected when:
- Appian application gets promoted to different environments
- New functionality is created
- Concurrent development teams are established
Fast forward to a particular step in a workflow to perform manual testing from there

When Should Automated Testing Be Implemented

Automated testing should be implemented early in a project to prevent buildup of functionality for which test scripts must be written. The longer a team waits to set up automated testing, the more burdensome it can become to do so. Conversely, if test scripts are written for functionality that is highly likely to change, it can be time-consuming to update them to keep up with changing requirements. So, a project team must work together to achieve a balance between these alternatives by determining when and for what purposes to design automated testing scripts.

How Much Should Automated Testing Cover

It is not recommended to have 100% test coverage of an application through Automated Testing due to the below reasons:

It is time consuming to plan/implement test scripts and run the tests to cover the entire application.
We currently do not have a method to gauge completeness of test coverage for an application.
Some areas of the application may change frequently over time and integrations may depend on external systems.

These factors can make it difficult to get a good return on the time investment put into building test scripts to cover all functionality in an application.Given that 100% of the application cannot reliably be validated through automated testing, the core team (developers, PO, QAs) must collaborate in order to identify highest priority items to be addressed. Teams should consider factors such as level of effort to create new automated tests and level of risk in determining where to focus test coverage. Based on this collaboration, the automated testing suite can be incrementally updated to ensure highest value areas are targeted first.

Automated testing is not the same as performance testing. To find more information on performance testing best practices and tools such as JMeter and Loadrunner, see Performance and Load Testing.

Automated Testing Tools for Appian Applications

The following tools can be used to automate testing for Appian applications. The Tools In Appian section describes automated testing features that come OOTB with Appian, which should be used wherever possible. The External Tools section includes the available tools which were not built for Appian, and the Tools Built for Appian section describes tools built for Appian from external tools to facilitate automated testing in Appian.

Tools in Appian

Expression Rule Test Cases: Test cases can be configured for expression rules to test outputs with any combination of inputs. These function as automated tests built into the expression rule object. See the documentation for more information and instructions on when and how to use expression rule test cases. By importing the Automated Rule Testing application to an environment, administrators can run all test cases regularly and leverage reporting on failures and successes. This will help identify bugs in expression rules faster, speed up regression testing after rules have changed, and make smoke testing deployments even faster.

External Tools

These should generally only be used when necessary. Otherwise, it is recommended to use FitNesse For Appian or Appian’s Selenium API with Cucumber (described in the Tools Built for Appian section below) because these are preconfigured to work for Appian applications.

Selenium: Selenium is an automated testing tool that is able to control a web browser. Selenium has two different products: WebDriver and IDE. The WebDriver is a collection of language specific bindings that drive a web browser while the IDE is an add-on to Firefox that is able to record and playback interactions with the web browser.

For more information, see the Selenium Website

FitNesse: FitNesse is automated testing software which uses a wiki language and allows for a low barrier to entry and ease of use. FitNesse test scripts and test suites are created in the wiki language that map out to functions written in a development language that wrap a Selenium Webdriver to perform actions on an Appian application.

For more information, see the FitNesse Website

Cucumber: Cucumber is an automated test tool utilizing Behavior Driven Development (BDD) that allows testers to specify test scenarios in a human readable form. Cucumber can be used to create test scripts in plain language with Gherkin syntax. One benefit of Cucumber is that the Product Owner or business users are able to write test cases without a technical background. These test scripts map to functions in a development language (such as Java or Ruby) that wrap a Selenium Webdriver to perform the specified actions on an Appian application.

For more information, see the Cucumber Website

Tools Built for Appian

Appian has created the following tools to reduce the amount of work required to automate testing of Appian applications.

Appian Selenium API: The Appian Selenium API allows you to run Appian UI tests directly from a JUnit Test Case, create your own Gherkin steps and step definitions with Cucumber, and run tests from any java based test tool of your choice without having to create the necessary xpath for selenium to interact with Appian. When using Cucumber, it is recommended to use this API to customize step definitions to match the business users’ phrasing.

Download the Appian Selenium API

FitNesse for Appian: Appian has written WebDriver fixtures to leverage Selenium and FitNesse to create FitNesse for Appian. This tool is easier to set up than Fitnesse and provides a faster way to build automated tests for Appian applications. This is complemented by the FitFam application, which allows users to create FitNesse test scripts for complex interfaces solely by interacting with the interface.

Download FitNesse for Appian
For more information, see the FitNesse for Appian Documentation
For implementation guidance, see the FitNesse for Appian Best Practices Play

Cucumber for Appian: Cucumber for Appian is a client-side tool that provides a sample set of step definitions similar to those provided by FitNesse for Appian. Note that these step definitions are not application specific. Features and scenarios written with these sample step definitions will not embrace the Behavior Driven Development (BDD) aspects of Cucumber. Cucumber for Appian is a good starting point for teams not familiar with Cucumber to get familiar with Cucumber before writing their own cucumber step definitions in Java. Additionally, the sample step definitions will allow testers to write a fairly complete set of tests without needing to know Java.

Teams experienced in writing automated tests as code might find the sample step definitions provided by Cucumber for Appian limiting. For example, gherkin syntax does not allow for saving variables between steps or looping. We recommend leveraging the Appian Selenium API to write your own step definitions for testers that want to trade the simplicity of Cucumber for Appian with the power provided by code. Custom Step Definitions in tandem with the Appian Selenium API will allow you to write future proof tests that will work between upgrades and embrace BDD.

Download Cucumber for Appian

For more information, see the Cucumber for Appian Playbook Play

Tags: Delivery, testing, Architecture

LDAP Synchronization

joel.larin — Thu, 11 Jun 2026 21:51:28 GMT

Current Revision posted to Guide by joel.larin on 6/11/2026 9:51:28 PM

Overview

Over time, user accounts need to be created, updated, and deactivated. Customers who have an existing user directory can use the LDAP Tools plug-in to automatically mirror these changes to Appian without requiring users to work manually through the web interface or with CSV files.

Periodically synchronizing users with a directory service ensures that only authorized users have accounts in Appian and that their user profiles are consistent with the system of record. Furthermore, synchronizing users between Appian and the directory service provides Shared Sign On features when using Appian native authentication. Customers can elect to combine LDAP sync with external authentication mechanisms such as SAML or Kerberos to offer true Single Sign On capability.

User Profile Synchronization

There are several ways LDAP can be used to create accounts in Appian. The LDAP Tools plug-in smart service node can be used to update Appian user profiles in bulk from returned LDAP queries. The data that can be synchronized includes all the default user profile fields (e.g., first name, last name, address, phone, supervisor, title, etc.) as well several custom fields. These details can then be used to create and update accounts and modify group membership.

Another common method to generate user accounts is to have them updated and populated with details from LDAP when a user logs in. Although this approach is useful for customers who don't have an existing Appian user directory or who don't want to synchronize users in bulk using LDAP sync, users are not visible in the system and cannot be added to groups (e.g., for task assignment) prior to their initial logon. Furthermore, this create-on-login paradigm does not support user deactivation. This approach requires the use of a custom Java extension to the external system and must be maintained independent of Appian. This is outside the scope of the LDAP tools plug-in.

It is recommended to use the first approach in a nightly batch process. This handles the issues discussed above and ensures that the authorized user list is up to date. Please refer to the LDAP Sync application included with the plug-in for more information.

Important Considerations

All operations by the plug-in are driven by LDAP queries on object classes, attributes, and groups. As such, if you are not familiar with LDAP terminology, please proceed with caution.

Important: When running LDAP sync, it is possible to unintentionally import an entire user directory.

While the process can facilitate the creation of users in Appian, users accounts can never be deleted, only deactivated. Therefore, it is important to ensure that only the users you expect to be imported is actually imported. In a pre-production environment, test the queries using the Configure LDAP Synchronization action included in the LDAP Sync application.

Prerequisites

Before attempting to use the LDAP Tools plug-in, identify the following information for your environment:

Item	Example
Full LDAP Server URL	ldap://localhost:389
Service Manager Username	cn=Admin
Service Manager Password	secret
Narrow LDAP Search Filter	(&(objectClass=person)(memberof=CN=Finance,OU=Users,DC=appian,DC=com))
Mapping of Attributes to Appian User fields	uid, givenName, sn, and mail map to the Username, First Name, Last Name, and Email address of a created account

LDAP Sync Application

The LDAP Tools shared component includes an application that, when configured, synchronizes the directory service users to Appian. The application will also manage Appian group membership.Note: The application only synchronizes users and their group association within Appian, it does not create groups to mimic the directory service structure.

The process automatically:

Creates Appian users that do not exist
Deactivates Appian users that have been removed from the directory service
Reactivates previously deactivated Appian users
Updates Appian users with any changes made to their respective directory service entries

This process can be run nightly ensuring all authorized users have accounts. If more frequent updates are required, especially when dealing with large group sizes, they can be scheduled during off peak hours to ensure the update process does not overlap with high volume usage.

Use Cases

The following examples demonstrate the cases the nightly synchronization handles.

Case 1 - A new entry, John Smith, is added to the directory service. This entry is captured by at least one of the LDAP queries run during the nightly LDAP synchronization process and a new Appian user with the same details is created.

Case 2 - The user added in the previous case is updated. Additionally, Jane Doe, is removed from the directory service. Both of these changes are captured by the nightly synchronization. In Appian, the first name john.smith user account is updated to Jonathan. The jane.doe account is not returned by any of the LDAP queries and is then deactivated in Appian.

Case 3 - An existing directory service entry is modified so that a user is removed from a directory service group. This results in the none of the LDAP queries returning this user. The user is deactivated and removed from the associated Appian group.

LDAP Sync Tutorial

Setup up a directory service. Please skip to Step 2 if you already have a directory service configured. For the purposes of this tutorial, we recommend using openDJ. During the "Directory Data" step of the installation define your Base DN and automatically generate sample data.
- Define the Base DN as dc=appian, dc=com and create 100 users.
Browse the directory with a third-party client such as JXplorer and confirm that the entries to be imported have the minimum basic user criteria. Also take note of the expected number of created Appian users as well as any distinguishing attributes that can be used to generate a targeted search filter.
Deploy the LDAP Tools plug-in on your Appian instance.
Import the LDAP Sync application into your environment.
Set up a Secure Credential Store to include the authentication credentials for the directory service:
- Navigate to the Administration Console.
- Navigate to Third-Party Credentials.
- Click Create.
- Enter a Name, this is the secured credential store (SCS) key, e.g., ldap.acme.
- Click +Add field to create a new field named username, this is the relative distinguished name (RDN) for the ldap administrator, e.g. cn=admin.
- Click +Add field to create a new field named password, this is the password for the administrator user, e.g., secret.
- Select LDAP Tools in Plug-ins field.
- Click Save.
In Tempo, click Actions, and then click Configure LDAP Synchronization.

Fill out the following required fields:

Field	Description	Example
Protocol	Protocol used to connect to ldap server	ldap or ldaps
Server	Host running the ldap server	ldap.server.com
Port	Port used to connect to the ldap server	389 or 636
Secure Credential Store Key	Name of third-party credential contains ldap admin details	ldap.acme
Connection Type	Set to ssl if using a non-standard key store	clear or ssl
All LDAP Users Group	If a user is a member of this group, but not returned by any of the LDAP group filters, the user is deactivated	All Users
User Attribute Mapping	Mapping of ldap attributes to Appian user profile fields, the following are required: Username, First Name, Last Name, Email	uid, givenName, sn, mail

Create at least one group filter which is used to synchronize the LDAP query results with membership to an Appian group:
- In the Group Membership section, click +Add Item to add a new Group Filter.
- Enter a Display Name for the filter, this is used to name the process instances which synchronize this group.
- Enter the Base DN for the query, if left null the entire directory is searched.
- Enter the LDAP Filter used to query the desired subset of users.
- Enter the Appian Group whose members should be determined by this filter.
Check the box next to the newly created row and click Test Filter.
- This action returns either the results for the filter or an error and a suggested remedy.
- The fields displayed in the results table correspond the mapped attributes in the User Attribute Mapping section.
Once all filters have been created and tested click Submit to save the settings.
To turn on nightly sync do the following:
- Open the Configure LDAP Synchronization action.
- Check the Enable LDAP Sync checkbox.
- Enter the time when the sychronization process should runNote: this requires republishing of the LDAP - Scheduled Job process model in order to integrate the new start time.
- Verify process runs at appointed time and daily thereafter.

Troubleshooting

Below are some of the most common errors encountered when using the plug-in. Confirm with the plug-in’s documentation and your directory services’ manual for more specific information.

Error Code 12

An error code 12 response is received when using the ldapsearch function in Appian, despite confirming that the directory service is browsable and searchable using third-party tools such as JXplorer:

LDAP: error code 12 - Unsupport critical control 2.16.840.1.113730.3.4.9

LDAP: error code 12 - LDAP_UNAVAILABLE_CRITICAL_EXTENSION

The plug-in presumes that your directory service supports virtual list view request control (VLV). If this is not the case, update the Virtual List View Control Supported field using the Configure LDAP Synchronization action.

Error Code 49

An error code 49 response is received when using the ldapsearch function in Appian:

LDAP: error code 49 - Invalid Credentials

Check the Secure Credential Store and confirm that your logon credentials are correct. Passwords are case sensitive. The username must be entered with its full RDN (for example, cn=admin, not admin).

Unable to Bind to LDAP Server

An Unable to bind to LDAP server error is usually returned when the directory service is down. Confirm that the server is operational, has an IP Address, and is not blocked by any firewall before trying again.

Tags: integrations, Architecture

Integrating with DocuSign

joel.larin — Thu, 11 Jun 2026 21:51:02 GMT

Current Revision posted to Guide by joel.larin on 6/11/2026 9:51:02 PM

Key DocuSign Concepts

DocuSign provides electronic signature technology and digital transaction management through a web app. In the DocuSign lifecycle, the process ends with a signed, voided, or rejected document. Because of this, it’s important to understand how DocuSign structures its documents and maintains signature validity. DocuSign uses the concept of envelopes and documents to allow seamless signing experiences while preserving document independence

Envelope

An envelope can contain one or more documents, the fields in the document, recipient info, delivery progress, sender information, security and more.

Document

A document is the lowest-level object on which an intact signature seal can be placed. Multiple documents can be added to an envelope. After signing, these documents can then be extracted individually if needed.

Signature Seal

Electronic seals are used to show evidence of origin and integrity of documents. One of the ways DocuSign uses seals is to ensure the validity of an electronic signature on a document and to ensure that no document tampering has been done after signing. If a document is split up or changed in any way after signing, the seals will be broken and the signatures are invalidated. If pages or documents need to be independently extracted post signing, to preserve seal integrity, the items need to be split into “documents” on the same envelope.

Connectivity from Appian to DocuSign

Setup of DocuSign requires admin access on the DocuSign account. For easy production deployment, you will want the sandbox to be configured with an account linked to your Production Account.

Integration to DocuSign in production requires the promotion of an API key by following DocuSign's Go-Live Steps from each environment. The following guide will highlight setting up a connection for a single Appian environment to send single-document envelopes to a single signer.

There are three common methods for setting up authentication and authorization between Appian and DocuSign.

1. Service Account Integration (JWT Grant)

This method uses a single service account DocuSign user. The integration calls to DocuSign are made as this service account user. The first step necessary is to login to the DocuSign account with Admin privileges that the client wishes to use for their integration and retrieve some key pieces of information.

DocuSign Setup Steps for Demo Environment

Login to https://demo.docusign.net/ with Admin privileges.
Navigate to the Settings tab.
Click on Apps and Keys (under Integrations in the left navigation).
Copy the User ID, API Account ID, and Account’s Base URI to a location where they’ll be easily copied.
Click Add App / Integration Key.
Add an appropriate App Name, ensuring you keep in mind the number of environments you will be connecting.
Copy the Integration Key to the same location where the information in Step 4 was stored.
Under Authentication, select Yes for the question on whether your application can securely store a client secret. (Responding No to this question also works for JWT grant as this method uses the RSA private key as opposed to the client secret key used in the Authorization Code grant method).
Under Service Integration, click Generate RSA and copy the private key to the same location where the information in Step 4 was stored.
Click SAVE.
Follow the steps required to obtain individual consent for your application to act on a user’s behalf.

Appian Setup Steps

The easiest way to interact with DocuSign in Appian is through the use of a Connected System.

Create a Connected System using proper naming conventions.
Select DocuSign.
Add an appropriate name and description.
Under Authentication, select JWT Grant.
Paste the Instance URL (Account’s Base URI), the API Account ID, API Username, Private RSA Key, and Integration Key.
For the private key, the copied text needs to include “ -----BEGIN RSA PRIVATE KEY----- ” at the beginning and “ ----- END RSA PRIVATE KEY----- ” at the end.
Click TEST CONNECTION.
When you get a Connection successful alert, click CREATE.

2. Per User Authorization (Method 1) - Authorization Code Grant

Rather than using a service account to make the calls from Appian to DocuSign, the user authorizes Appian to make calls to DocuSign on their behalf using their DocuSign account. Please note that this method requires providing the user an authorization link within an Appian SAIL form before making a call on their behalf. If calls on their behalf fail, catch the error, and again provide the user with an authorization link to reauthorize.

DocuSign Setup Steps for Demo Environment

Follow steps 1-7 from the Basic Authentication section above.
Under Integration Key, select Authorization Code Grant.
Add a Secret Key and copy the value.
Add the [APPIAN_URL]/suite/oauth/callback URL to the Redirect URIs list.
Click SAVE.

Appian Setup Steps

The easiest way to interact with DocuSign in Appian is through the use of a Connected System.

Follow steps 1-3 from the JWT Grant Authentication section above.
Under Authentication, select Authorization Code Grant.
Paste the Instance URL (Account’s Base URI), the API Account ID, Integration Key, Secret Key into the Appian setup page then select the DocuSign Environment.
Click AUTHORIZE to authorize Appian to make calls on the logged in user’s behalf (you may need to enter your DocuSign credentials at this time).
When you get a Connection successful alert, click CREATE.

3. Per User Authorization (Method 2) - JWT Grant with Organizational Consent to Act on Behalf of All Users

As in method 1, this method also uses each individual user’s Docusign account to make the integration calls, however the user is not required to manually authorize Appian to act on their behalf. A DocuSign admin provides organizational consent for all users. This method requires using the JWT Tools plugin to accomplish the generation of access tokens and cannot use the DocuSign connected system for integrations.

This approach is often paired with the Service Account Integration method such that certain calls (Send Envelope) use the JWT Tools plugin and others (Download Document) use the Appian Connected System.

Docusign Setup

Update the account settings on DocuSign by following these steps.
Follow the steps to implement JWT Grant from the DocuSign documentation.

Appian Setup

Download JWT Plugin from the app market.
Create a third party credential key via the Admin Console (Admin Console -> Third Party Credentials -> Create).
1. Name: Required field, select a unique easy-to-use name.
2. Key: Appian will auto generate it from the name.
3. Description: Optional field, enter an appropriate description.
4. Plug-ins List: Optional field, type “JWT” (should show up to select).
5. Credentials: Optional field, add two fields with the following details.
6. Enter appianPrivateKey as Field Name and value as the DocuSign Admin Account’s generated Private RSA Key (note: remember to copy the entire —begin RSA private key— to —end RSA private key). Check the Mask box to hide it from the front end.
7. Enter appianPrivateKeyPassword as Field Name and leave the value empty.
8. Test Connection: Optional, leave it blank and click “Save”.
Generate Admin’s Access Token.
1. Create an expression rule to generate the “Access Token.”
  1. Add a rule input for user ID as this rule will be used to generate JWT for the admin as well as the user to impersonate.
  2. Use function - createdocusignrsajwttoken() provided by the JWT Plug-in.
  3. Note that the plug-in requires you to follow the order of the parameters.
  4. Use guidance from DocuSign to generate the JWT.
2. Create an integration to generate the admin access token.
  1. Add a rule input for passing the JWT generated in Step 3a(i)
  2. Under Request Body select “Content Type” as Multipart and provide assertion which will the generated Admin JWT and grant_type as "urn:ietf:params:oauth:grant-type:jwt-bearer"
  3. For additional guidance, follow the DocuSign documentation
  4. Parse the access token from the response.
Generate Sender’s Access Token
1. The admin’s generated token will be used to retrieve the sender’s information (as long as they are part of the Organization in DocuSign)
2. Create an integration to retrieve user information (DocuSign Documentation) using their email address registered with DocuSign and the admin access token generated in Step 3a(i).
  1. URL: The “Account ID” will be available in the DocuSign settings, recommended to create a constant to store the value. Note that the URL will vary depending on the environment.
  2. Query Parameters: Add “email” which will be the user’s email address.
  3. Headers: Add “Authorization” where the value will be (in expression mode) “Bearer” + the admin’s access token.
3. Parse the “userId” from the generated response and use it in the rule created in Step 3(a) to retrieve the sender’s JWT.
4. Use the integration created in Step 3(b) to generate the sender’s access token.
  1. The rule input value will be the sender’s generated JWT.
  2. Parse the access token from the response.
Create integration to send envelope as the user via DocuSign
1. With the sender’s access token, DocuSign integrations can be called to create and send envelopes, etc. Note that we cannot use the out of the box Docusign Connected System for any integrations that need a bearer token.
2. In the Authorization Header for the integration, pass the sender’s generated access token.

DocuSign Integrations

Connectivity can quickly be validated with a GET Account call. This call will retrieve the account’s basic information but does require having the API Account ID

There are a number of actions that a developer can perform on a DocuSign envelope and the documents contained within. An introduction to the concepts of DocuSign’s Object model can be found on their eSignature Object Model Overview. Users of this guide are encouraged to read through DocuSign’s documentation to learn more about what is possible when integrating with DocuSign.

Implementing Integrations in Appian

Create Envelope

Use the Appian Connected System OOTB operation to Create and Send Envelope which utilizes DocuSign’s Create Envelope REST API. The request body is expressionable in Appian and the DocuSign documentation page linked above has great JSON examples of configurations with different numbers of documents, signers, recipients, tabs, etc.

In Appian, an example expression for a single signer with an embedded signing ceremony might look like this:

a!toJson(
  {
    /*documents: - handled by Appian Integration Object*/
    /*status: - handled by Appian Integration Object*/
    emailSubject: ri!subject,
    recipients: {
      signers: {
        {
          autoNavigation: true,
          clientUserId: ri!signer.username,
          email: ri!signer.email,
          name: ri!signer.fullName,
          recipientId: ri!signer.recipientId,
          recipientSuppliesTabs: false,
          routingOrder: "1",
          tabs: {
            dateSignedTabs: {
              {
                anchorString: "today_1_r",
                anchorXOffset: "0",
                anchorYOffset: "0",
                anchorIgnoreIfNotPresent: "true",
                anchorUnits: "inches",
                optional: "false"
              }
            },
            initialHereTabs: {
              {
                anchorString: "init_1_r",
                anchorXOffset: "0",
                anchorYOffset: "0",
                anchorIgnoreIfNotPresent: "true",
                anchorUnits: "inches",
                optional: "false"
              },
              {
                anchorString: "init_1_o",
                anchorXOffset: "0",
                anchorYOffset: "0",
                anchorIgnoreIfNotPresent: "true",
                anchorUnits: "inches",
                optional: "true"
              }
            },
            signHereTabs: {
              {
                anchorString: "sig_1_r",
                anchorXOffset: "0",
                anchorYOffset: "0",
                anchorIgnoreIfNotPresent: "true",
                anchorUnits: "inches",
                optional: "false"
              },
              {
                anchorString: "sig_1_o ",
                anchorXOffset: "0",
                anchorYOffset: "0",
                anchorIgnoreIfNotPresent: "true",
                anchorUnits: "inches",
                optional: "true"
              }
            },
            textTabs: {
              {
                tabLabel: "firstText",
                anchorString: "text_1_r",
                anchorXOffset: "0",
                anchorYOffset: "0",
                anchorIgnoreIfNotPresent: "true",
                anchorUnits: "inches",
                optional: "false"
              },
              {
                tabLabel: "secondText",
                anchorString: "text_2_r",
                anchorXOffset: "0",
                anchorYOffset: "0",
                anchorIgnoreIfNotPresent: "true",
                anchorUnits: "inches",
                optional: "false"
              }
            }            
          }
        }
      }
    }
  }
)

Noteworthy Fields

clientUserId - this field should only be populated if the signing ceremony will be embedded in Appian for the recipient. Populate using the Appian username.

recipientId - this field needs to be unique for the recipients within the envelope. If there is only one recipient, use the number 1. If there are multiple, use unique integers for each.

tabs - this implementation uses the anchor string method (see other tab creation methods here and tab types here) for designating input fields for the end user. For example, the document template has transparent white text on a white background of “sig_1_r” where a signature is required.

Signing Documents

Remote

If clientUserId is not populated, the signing ceremony will be remote. The user will receive an email from DocuSign to perform the signing ceremony in DocuSign.

Embedded

If clientUserId is populated, the signing ceremony must be embedded. The user will not receive an email nor have the option to perform the signing ceremony in DocuSign, as the application is responsible for the embedded signing experience.

Use the Appian Connected System OOTB operation to Generate the Recipient Signing URL which utilizes DocuSign’s Create Embedded Recipient REST API. Since this operation is a POST call and the DocuSign URL must be used within 5 minutes, the appropriate way to trigger this integration call is on button-click within a SAIL interface each time the user opens the form. It should not be called within a process model since the user may close the task and come back more than 5 minutes later. It cannot be called as part of local variable instantiation since it is a POST call and not a GET call. An example implementation might look like this:

rule!APP_CMPT_requestBoxLayout(
  label: "Acknowledgement",
  contents: {
    a!richTextDisplayField(
      label: "Rich Text",
      labelPosition: "COLLAPSED",
      value: {
        a!richTextItem(
          text: { cons!APP_TXT_DS_ACKNOWLEDGEMENT },
          style: { "EMPHASIS" }
        )
      }
    ),
    a!buttonArrayLayout(
      buttons: {
        a!buttonWidget(
          label: "OK",
          saveInto: rule!APP_INT_DS_genEmbeddedSigningURL(
            envelopeId: ri!envelopeId,
            signer: ri!signer,
            onSuccess: {
              a!save(
                local!embedUrl,
                index(fv!result, "url", null)
              )
            },
            onError: {
              a!startProcess(
                processModel: cons!APP_PM_INTEGRATION_ERROR_TASK,
                processParameters: {
                  integrationError: fv!error,
                  integrationName: cons!APP_TXT_DS_GEN_URL_INT_NAME,
                  isRetryError: false,
                  request: = "Generate signing URL for envelope " & ri!envelopeId,
                  requestId: ri!requestId,
                  response: fv!result
                }
              ),
              a!save(local!generateUrlError, fv!error)
            }
          ),
          style: "PRIMARY"
        )
      },
      align: "END"
    )
  },
  showWhen: and(
    rule!GBL_isBlank(local!embedUrl),
    rule!GBL_isEmpty(ri!createEnvelopeError),
    rule!GBL_isEmpty(local!generateUrlError)
  ),
  style: "STANDARD"
)

Noteworthy Fields

Return URL - this is the URL that shows in the web content field of Appian after the (1) user completes the signature (2) user declines to sign OR (3) embedded DocuSign session times out after 20 minutes of inactivity, which is the DocuSign default. This URL cannot be an Appian URL, therefore the best option is a public URL hosted on the customer network, specifically designed to provide the end user with a useful message after any one of these three events occurs. The single message should cover all three scenarios since it will be displayed regardless of which event occurs.

Recipient User Name - this field needs to have the same value that you specified in the “name” field while creating the envelope in the Create and Send Envelope operation.

Design Tips

The embedding URL can be placed with Appian’s web content component on a SAIL form. If you provide an Appian submit button on the SAIL form, there is a risk that the user clicks that Appian button before completing the signing ceremony, which requires clicking a “Finish” button on the embedded form. To reduce this risk, prevent the user from submitting the form until the DocuSign Connect Webhook (see below) has informed Appian that the signing ceremony is complete by either:

1. Disabling the “Continue” button in Appian until DocuSign has called the Appian Web API and the application database is updated with a “Signed” status

a!columnLayout(
  contents: {
    a!richTextDisplayField(
      labelPosition: "COLLAPSED",
      value: a!richTextItem(
        text: "STEPS",
        color: "SECONDARY",
        size: "MEDIUM_PLUS",
        style: "STRONG"
      )
    ),
    a!forEach(
      items: {
        a!richTextDisplayField(
          labelPosition: "COLLAPSED",
          value: {
            a!richTextItem(
              text: "Sign",
              color: "SECONDARY",
              size: "MEDIUM",
              style: "STRONG"
            ),
            a!richTextItem(
              text: " the document",
              color: "SECONDARY",
              size: "MEDIUM"
            )
          }
        ),
        a!richTextDisplayField(
          labelPosition: "COLLAPSED",
          value: {
            a!richTextItem(
              text: "Click the",
              color: "SECONDARY",
              size: "MEDIUM"
            ),
            a!richTextItem(
              text: " Finish",
              color: "SECONDARY",
              size: "MEDIUM",
              style: "STRONG"
            ),
            a!richTextItem(
              text: " button at the top",
              color: "SECONDARY",
              size: "MEDIUM"
            )
          }
        ),
        a!richTextDisplayField(
          labelPosition: "COLLAPSED",
          value: {
            a!richTextItem(
              text: "Click this",
              color: "SECONDARY",
              size: "MEDIUM"
            ),
            a!richTextItem(
              text: " Refresh",
              color: "SECONDARY",
              size: "MEDIUM",
              style: "STRONG"
            ),
            a!richTextItem(
              text: " button until the",
              color: "SECONDARY",
              size: "MEDIUM"
            ),
            a!richTextItem(
              text: " Continue",
              color: "SECONDARY",
              size: "MEDIUM",
              style: "STRONG"
            ),
            a!richTextItem(
              text: " button below is enabled",
              color: "SECONDARY",
              size: "MEDIUM"
            )
          }
        ),
        a!richTextDisplayField(
          labelPosition: "COLLAPSED",
          value: {
            a!richTextItem(
              text: "Click the",
              color: "SECONDARY",
              size: "MEDIUM"
            ),
            a!richTextItem(
              text: " Continue",
              color: "SECONDARY",
              size: "MEDIUM",
              style: "STRONG"
            ),
            a!richTextItem(
              text: " button below",
              color: "SECONDARY",
              size: "MEDIUM"
            )
          }
        )
      },
      expression: {
        a!columnsLayout(
          columns: {
            a!columnLayout(
              contents: a!cardLayout(
                contents: a!richTextDisplayField(
                  labelPosition: "COLLAPSED",
                  value: a!richTextItem(
                    text: fv!index,
                    color: "SECONDARY",
                    size: "MEDIUM_PLUS",
                    style: "STRONG"
                  ),
                  align: "CENTER"
                ),
                style: "STANDARD"
              ),
              width: "EXTRA_NARROW"
            ),
            a!columnLayout(
              contents: a!sideBySideLayout(
                items: {
                  a!sideBySideItem(item: fv!item, width: "MINIMIZE"),
                  a!sideBySideItem(
                    item: a!buttonArrayLayout(
                      buttons: a!buttonWidget(
                        icon: "refresh",
                        tooltip: "You may need to refresh more than once",
                        saveInto: [INSERT QUERY HERE],
                        style: "NORMAL"
                      ),
                      marginBelow: "NONE"
                    ),
                    width: "MINIMIZE",
                    showWhen: fv!index = 3
                  )
                },
                alignVertical: "MIDDLE"
              )
            )
          },
          alignVertical: "MIDDLE"
        )
      }
    )
  },
  width: "MEDIUM"
)

2. If there is no subsequent form to activity chain the user to and the signature is the last step in the workflow, one option is to not provide any Appian buttons at all then when the DocuSign Connect Webhook calls the Appian Web API, start a process model that messages the task form to hit an exception flow that ends the task and process model.

Receiving Envelope Status Updates

DocuSign has API rules for their web services and the most relevant rule is that apps are limited to one GET status request per unique envelope per 15 minutes. This means that process models should NOT have a node (and SAIL interfaces should not have a local variable) that checks the envelope status in DocuSign directly or regularly.

Instead, set up DocuSign Connect to call an Appian Web API when a relevant change to an envelope (such as it being signed) has occurred and start an Appian process model to begin post-processing (write the status to the database and download the document) at this time.

Setting Up DocuSign Connect

Appian Setup

Create an Appian group for APP DocuSign Service Accounts.
Create an Appian Web API as a POST method.
Sections below will help define the expression for this object.
Give the Appian group viewer rights to the Web API.
Create a Service Account in the Admin Console under Web API Authentication > OAuth 2.0 Clients > Create.
Basic Authentication is possible to use in place of OAuth 2.0, but is not recommended due to poor security and expiring password. OAuth 2.0 is the industry-standard protocol for authorization, and should generally be used when possible.
Copy the Client ID, Client Secret, and Token Request Endpoint to a secure location where they can be retrieved, as the secret will not be displayed again in the admin console.
Add the service account to the Appian group. Also ensure that the service group has at least ‘Initiator’ privileges to the process model called in your Appian Web API.

Since DocuSign Connect supports Basic Authentication but neither the username or password can be null, an Appian basic user account with a username and password must be created from DocuSign Connect to use when calling the Appian Web API

DocuSign Setup

Login to the DocuSign with Admin privileges.
Navigate to the Settings tab.
Click on Connect (under Integrations in the left navigation).
Select Add Configuration > Custom.
Add the setup details including Web API URL.
Choose the data format (Legacy vs REST V2.1). When the Legacy format is chosen, the message from Docusign is an older XML format whereas the REST v2.1 is a newer JSON format that is easier to process, and is the recommended option for Appian Integrations.
Select the user envelopes that should trigger the webhook callback. The correct value will depend on the REST API authentication method and customer DocuSign setup.
Select the events that should trigger the webhook callback.
Check the box to include OAuth.
Click ADD CONFIGURATION.
Select the OAUTH 2.0 tab.
Enter in the Client ID, Client Secret, and Authorization Server URL.
Click SAVE.

Parsing the DocuSign Connect Request - (REST v2.1)

The webhook body is JSON formatted and can be accessed with standard dot notation or the index() function. You may extract the status and the envelopeId from the body as shown here:

a!localVariables(
  local!requestBody:a!fromJson( http!request.body),
  local!envelopeDetails: a!map(
    event: index(local!requestBody, "event", {}),
    envelopeId: index(
      index(local!requestBody, "data", {}),
      "envelopeId",
      {}
    ),
    
  ),
  a!startProcess(
    processModel: cons!VT_PM_RECEIVE_ENVELOPE_STATUS,
    processParameters: { envelopeDetails: local!envelopeDetails,
    requestBody:local!requestBody},
    onSuccess: a!httpResponse(
      statusCode: 200,
      headers: {},
      body: "Appian has received the envelope status and saved it."
    ),
    onError: a!httpResponse(
      statusCode: 302,
      headers: {
        a!httpHeader(
          "referer",
          http!request.queryParameters.referer
        )
      },
     
    )
  )
)

Parsing the DocuSign Connect XML (Legacy)

The webhook body contains XML information about the envelope event, including the document ID, envelope ID, and envelope status. To be memory efficient, extract these values directly in the Web API expression rather than saving the XML into process variables.

While the XML can be configured to include the base64 representation of the signed document, DO NOT send or extract this value and save it into an Appian local variable or process variable since this will have negative impacts to the Appian memory profile. Instead, kick off a process model that downloads the document using the Appian OOTB operation to Download Document from Envelope which creates an Appian document in a specified folder, skipping the need to handle the base64 representation in variables.

If extracting dateTimes out of the XML, make sure to account for the time zone of the value since these can come in the signer’s time zone depending on the setup.

Using XPath

a!localVariables(
  /*Have to remove namespaces from the XML to be able to use xpath snippet easily */
  local!cleanXML: substitute(
    substitute(
      ri!docusignXML,
      " xmlns:xsd=""http://www.w3.org/2001/XMLSchema"" xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"" xmlns=""http://www.docusign.net/API/3.0""",
      ""
    ),
    " xsi:nil=""true"" ",
    ""
  ),
  /* Apply the xpath that you're looking for based on the values provided. Always returns the first one. */
  'type!{urn:com:appian:types:APP}APP_H_DocuSignEventNotification'(
    docusignDocumentId: xpathsnippet(
      local!cleanXML,
      "/DocuSignEnvelopeInformation/EnvelopeStatus/DocumentStatuses/DocumentStatus/ID/text()"
    ),
    envelopeId: xpathsnippet(
      local!cleanXML,
      "/DocuSignEnvelopeInformation/EnvelopeStatus/EnvelopeID/text()"
    ),
    docusignStatus: lower(
      xpathsnippet(
        local!cleanXML,
        "/DocuSignEnvelopeInformation/EnvelopeStatus/Status/text()"
      )
    )
  )
)

Using XML Parser Plugin

The xmltojson() plugin function can also be used in conjunction with a!fromJson() to turn the XML into an Appian dictionary that can be read using the index() function.

Download Signed Document

After the XML has been parsed and the status has been verified as “completed”, use the Appian OOTB operation to Download Document from Envelope and utilize the document as needed within the Appian application.

Promoting DocuSign Configurations to Production

DocuSign Integration Key

DocuSign integration keys cannot be created directly in production. The key is instead promoted from the demo environment for the customer account to the production environment for the customer account. This includes an automated API review in the demo environment for which a selected day of at least 20 API calls are reviewed to ensure no API violations. Plan for this process in the application deployment guide.

DocuSign's Go-Live Steps

DocuSign Connect

The DocuSign Connect setup is done manually for lower environments and production. Plan for these manual steps in the application deployment guide.

DocuSign Connect

Tags: integrations, Architecture

FitNesse for Appian Best Practices

joel.larin — Thu, 11 Jun 2026 21:50:39 GMT

Current Revision posted to Guide by joel.larin on 6/11/2026 9:50:39 PM

Introduction

This play includes tips for organizing, writing, and running tests in FitNesse for Appian, as well as designing Appian applications for testing with FitNesse. This is intended to complement the existing documentation that comes with FitNesse for Appian. The existing documentation, the FitNesse for Appian Cheat Sheet, and examples can be accessed from the FitNesse for Appian home page, shown below.

It is highly recommended to read the FitNesse for Appian documentation before reading this play to have the necessary context for the best practices described. For more general FitNesse documentation, visit the FitNesse Full Reference Guide.

For additional information on Automated Testing with FitNesse, visit the Automated Testing and Automated Testing with FitNesse for Appian pages.

Organizing Tests

FitNesse Page Types

FitNesse is comprised of Static, Suite, and Test pages. The image below shows examples of each type of page and how they are used. More information on each page type and what they should include can be found in the “Organizing Tests” page of the FitNesse for Appian documentation and the FitNesse documentation on page properties.

Scenarios

Scenarios are reusable test scripts used to reduce the maintenance effort for repetitive tests. Scenarios are to FitNesse what a reusable expression rule is to Appian. If the same test script is repeated on several test pages, this script should be made into a scenario so that any changes to it will be reflected in all of its implementations. Note that scenarios can contain other scenarios.

A list of scenarios, called a “ScenarioLibrary,” can be created as a Test Page. This library can then be called by other Test Pages. The ScenarioLibrary Test Page can be located on a Static Page where other utility scripts are called, such as the Set up and Tear Down scripts (as pictured in Fig. 2). The image below demonstrates the structure of the ScenarioLibrary and how a Test Page calls its scenarios within the test flow. For more information on where the ScenarioLibrary is kept and used, refer to the “Scenarios” and “Organizing Tests” pages of the FitNesse for Appian documentation and the Scenario Table page in the FitNesse documentation.

Writing Tests

The primary Static page, shown below, is where Test Pages, Scenario Library, and Set Up/Tear Down scripts are located. Users can select Test Pages to edit or execute their tests. Users can select the Scenario Library link to edit the various scenario scripts that will be called from the Test Pages. The Suite Set up, Set Up and Tear Down scripts are used to initialize and cleanup Selenium drivers. Learn more about special pages like SuiteSetUp and SuiteTearDown in the FitNesse documentation.

Any script that should be executed before a Test Page should go into SetUp, and every script that should be executed after every Test Page should go into TearDown. See the figure below to understand how these tables are related to a Test or Suite Page.

Note: The Suite Set Up script initializes the test by navigating to the desired URL. So, the Suite Set Up script is specific to a single environment and will need to be adjusted for testing in new environments.

FitNesse for Appian includes a link to “FitNesse for Appian Cheat Sheet” at the bottom of the page, as shown in the image below. The Cheat Sheet lists all available methods for writing test scripts with formatting examples.

Some considerations to take when writing tests:

When the test environment performance is slow or when the script needs to be paused momentarily, an explicit wait time can be added.
- For example, use explicit waits ("| wait for | 1 minute |") between form inputs when you know a background process needs to be completed before the next step. In this scenario, not using an explicit wait may result in misleading errors caused by page slowness, not by errors on the interface.
Create test pages so they can be run independently and don’t require previous tests to be successful. That way, if any tests fail, the rest can still run.
Avoid hard-coding test data. Hard coded test data requires users to manually locate and update the test values whenever a change is needed. Instead, use variables to allow more flexibility in testing. Using variables keeps test data values in one place at the top of the script and allows testers to easily change test data and will reduce errors when tests need to be updated. The “Using Variables” section below provides more detail on how to use variables in FitNesse.

Using Variables

In Fitnesse, test data can be substituted with variables when needed. When creating test scripts or scenarios, it is a best practice to avoid hard-coding test data, which requires users to manually locate and update the test values whenever a change is needed. Instead, use variables to keep test data values in one place at the top of the script. Doing so will make changing test data easier and reduce the risk of errors when tests need to be updated. More detailed information on variables in FitNesse for Appian can be found in the “Using Variables” page of the FitNesse for Appian documentation.

There are three ways to use variables:

Markup Variables: Used within the Test Page or scenario script for variables that will be referenced throughout the entire script. Only markup variables, created through !define, can be used within expressions. More detailed information on this type of variable can be found in the Markup Variables FitNesse documentation. See the below example:

SLIM Symbols: Used within a Test Page or Scenario to set random string values. Example:

Test Variables: Used with JSON to capture multiple or complex variables at one time. Example:

Working With Test Data

If tests rely on data or processes to be in a certain state, it is useful to create the following two web API's per application: one to set up the test data, and the other one to clean up the test data. Test scripts can call these web APIs using “|get web api|” syntax which can be found in the FitNesse for Appian Cheat Sheet. Web APIs used for testing purposes should not be deployed to a Production environment.

Web API for Setting Up Test Data: If a test requires an existing approval task, or a record to be in a certain status before testing can proceed, those will need to be set up ahead of time. Web APIs can be used to generate data and write to tables, or to kick off processes, depending on what is required.

Web API for Cleaning Up Test Data: After tests are run and test data is no longer needed, a web API can be used to delete test data and clean up any changes in the app.

Running Tests

Create test user accounts for your application in all testing environments (Test, UAT, Sandbox as applicable). Do not use your own credentials. Using test user accounts will ensure that when testing, the logged in user is in the intended groups and has the appropriate permissions.
- To allow test users to work in FitNesse, you will need to include passwords for their usernames in the FitNesseForAppian/configs/users.properties file
Logout before logging in at the beginning of each test page. Subsequent tests which begin by logging a user in will fail if the user is already logged in.
Enable error screenshots using “|set take error screenshots to | true|” in test scripts to easily determine where tests have failed. These screenshots will be saved to the screenshot path folder, as defined by the “|set screenshot path to|SCREENSHOT_PATH|” method.

Designing Appian Applications for FitNesse

General Practices:

If you are using the character “|” in SAIL component labels or altText, it can only be readable if the value is surrounded by “!- <value> -!”. For example, if you are trying to use this syntax: “|populate field|Field Name|with|value|” and the field labeled Field Name has a “|” character in it, the correct syntax would be “|populate field|!-Field Name-!|with|value|”
Because FitNesse for Appian uses SAIL component labels to locate components, it is a best practice to create labels for all components so that test scripts can read those labels, rather than having to rely on the order of components in an interface. If displaying component labels does not make sense, use the labelPosition “COLLAPSED” option on the component so that the label will not display.

Cards and Rich Text

FitNesse for Appian generally utilizes field labels and indexes to identify and populate Appian components. However, more graphical clickable components such as rich text icons and cards do not have labels and are identified by other properties, like link labels, alt text, and accessibility text. Although these properties do not impact what the end user sees, it is a best practice to populate them with values that are intuitive to an end user or tester so that:

Applications can be tested using FitNesse for Appian without additional application changes
Testing teams can write automated tests using the intuitive label for the component and do not have to rely on development teams for information
The application is more readable by a screen reader

To achieve the above, follow these guidelines:

Cards: When creating cardLayouts, developers should always include accessibilityText which matches any text displayed to the end user. If no text is displayed (the card contains an icon only, for example), use text which is intuitive to testers.
- With Links: When creating a cardLayout with a link, always include link labels using the same text as would be used for cardLayout accessibilityText, described in the previous bullet.
Rich Text Icons: When creating rich text icons, use altText if testers will need to validate what the icon represents. For example, a check icon would have "Check" as its altText so that it can be verified on the UI.
- With Links: When using rich text icons with links, always include a caption for each clickable icon that matches the altText.

Example FitNesse Script:

Tags: testing, Architecture

How to Estimate your Appian Projects

joel.larin — Thu, 11 Jun 2026 21:50:14 GMT

Current Revision posted to Guide by joel.larin on 6/11/2026 9:50:14 PM

Skills Covered

Accurate project and resource requirements estimation is the cornerstone of any successful Appian project. However, accurate estimation isn't always easy: understanding which factors drive resourcing requirements and how is key to successful estimation.

Based on years of experience, this document outlines the methodologies used by Appian Expert Delivery Teams for project estimation as well as the factors that most impact an estimate.

Skills Checklist:

Balance speed of estimation process with requirements for accuracy.
Identify potential risks and required mitigation steps.
Clarify assumptions and caveats affecting the estimate.

Methodology

Appian’s project estimation approach combines two methods to derive an estimate with an expected variance of -10% to +25%.

Analogous Estimation
Consensus-based Estimation

The approach helps inform project control parameters - cost, time, and resources, during the proposal phase. This approach aligns with Agile delivery methodologies which acknowledge that requirements will change and solution development is an empirical process.

Discuss Use Case - Gain a concrete understanding of high-level business needs and drivers from the Project Sponsor or Business Subject Matter Expert.
Collect Estimation Factors - Gather details of factors that aect Appian solution complexity and project size.
Summarize Project - Document the use case, sizing factors, volumes and other details in a lightweight format (see template in
example 1).
Independent SME Review - Request independent review of Project Summary from 3-5 experienced Appian practitioners / Appian
Subject Matter Experts (see note below).
Estimation Session - A working session (typically 1-1.5 hours) to arrive at a common consensus re: project size, and clarify key
assumptions. The session is conducted by the creator(s) of the Project Summary document and attended by the Appian SMEs
that conducted the independent SME review.
Finalize Estimate - Opportunity to adjust the estimate based on new information or to adjust assumptions or other levers.
Communicate Estimate - Communicate the foundations of the estimate generated from the Estimation Session (5), description of
assumptions and any caveats.

The Estimation Session should be composed of experienced Appian practitioners. A diversity of Appian delivery experience drives better estimates. Indicative examples of project estimates are provided below.

Estimation Factors

The complexity of an Appian solution is determined by several factors, outlined below. Understanding these factors is necessary to arrive at accurate estimates of project size.

Records
Processes
User Interfaces
Reports
Integrations
Security Requirements
Outliers

Note that new versions of Appian (released quarterly) may contain features that reduce or even remove the complexity impact of a factor. See the latest Appian Product Documentation to keep up on new features.

1) Records

A Record is data that represents a central business concept. "Employee", "Vehicle", "Account" are all examples. Records provide a centralized view of a given business function, along with all of its connections to related records.

Assessment Criteria

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Impact on Estimate

Simple complexity categorization for Record data:
- Low - Simple fields with minimal interdependence, underlying data from a single data source.
- Medium - A few interdependent fields, underlying data from a small number of sources.
- High - Several interdependent fields, data manipulation before saving, underlying data from multiple data sources and integrations.
Volumes of Records processed.

Common Assumptions

Out-of-the-box Record List View will meet UX needs and the underlying data for the list comes from a single source.

Pro Tips

When specific details about Records are not known, use estimates (e.g. the average number of fields per record).
Remember: if there are no explicit security constraints on a Record, then all users would be granted access by default.

2) Processes

A Process is a unique workflow consisting of a series of steps that a Record or related element undergoes in order to achieve a business objective.

Assessment Criteria

Level of process complexity:
- Low - 5 to 10 steps in the Process. No data processing loops. Single step exception handling.
- Medium - 10 to 20 Process steps with one or two data processing loops, and with multiple sub-processes. Few exception ows with a low number of nodes.
- High - Over 20 Process steps with potentially multiple data processing loops, potentially multiple complex sub-processes or communication between processes. Complex exception ows involving multiple reviewers and subsequent review loops, data changes or integrations to other systems.
Volume of exception flows: The number of flows that handle the outcome of non-ideal events and which must be managed actively and gracefully.

Impact on Estimate

Highly complex workflows require extensive testing to ensure all pathways function as designed.
Complexity and number of exception flows drive the need for additional test data and assessment of all alternate pathways in the process.
If the Appian out-of-the-box Smart Services are not sufficient, it might be necessary to build new Appian Plugins to meet functional requirements. Creation of new plugins require developers with Java development skills, additional testing and deployment effort will increase overall project size.

Common Assumptions

All exception flows are clearly defined and describable.

Pro Tips

Exception paths, especially in earlier Application iterations, can be managed manually/externally to the Appian process. This helps bring the majority of the functionality to the end users quickly with the option of building more automation in subsequent iterations/phases.

3) User Interfaces

User Interfaces are pages composed of/configured from various components in the Appian UI components catalog and are the elements of the solution that end-users interact with directly. User Interfaces must be intuitive and compelling to use.

Impact on Estimate

Complex validations, such as:
- Limiting acceptable values for a field based on values present in multiple other fields
- Intelligent numbering that requires complex lookups or algorithms to compose and validate.
Rigid or uncompromising performance guidelines:
- Every page must load in under 200ms.
- File upload must be completed in 500ms.
Rigid or uncompromising UI design requirements:
- Appian provides easily configurable UI components, designed to be visually appealing, modern, and work in many form- factors. It does not, however, allow extremely fine control of visual elements (e.g. positioning with pixel level precision). The vast majority of business users find Appian user interfaces sufficient, and value the ability to rapidly build solutions over the fine control required to position specific UI elements with pixel-level precision.
Attempting to build a legacy system’s user experience in Appian:
- Appian is a modern platform and has a multitude of capabilities that legacy systems may lack. Attempting to design an Appian application to match a legacy system’s user experience would be a significant under-utilization of the true power and benefits of Appian and could lead to increased effort to build the solution.
Dynamically generating forms:
- A dynamically generated form is one that depends partially or wholly on external data (through a web service, database entries etc) for information on input fields, visual composition and validation.
It is possible to generate forms dynamically in Appian, but the Appian Best Practices team strongly recommends against this approach for several reasons:
- Standard Appian User Interfaces are versioned and therefore convenient to compare versions and identify problems quickly.
- Dynamic forms are not versioned in the same manner and identifying defects and fixing is time consuming and difficult.
- Any delay in retrieving the form information from a web-service or database is immediately visible to end-users as slow- loading. forms, leading to unpredictable performance.
- Testing dynamically generated forms is quite difficult and time-consuming in practice.

Pro Tips

Follow Appian UX recommendations and best practices (UX Design Guide).
Ensure that the development team is empowered to make UI decisions appropriate to the use-cases (i.e. let the experts build the best user experience).

4) Reports

Appian Reports are a sub-category of User Interfaces that share these characteristics:

Displays data in tables or charts (often with filtering capabilities).
Report interfaces do not allow users to update underlying data.
Common reporting data sources:
- Databases or data sets (e.g tables and views in the Appian database or an external database).
- Process model outputs.
- External data retrieved through integrations.

Impact on Estimate

These characteristics could increase the effort required to design, build, test and deploy reports

Complex data manipulation.
Aggregation of data from multiple systems
Complex filters

Common Assumptions

Standard Appian UI components will be used for charting and display.

Pro Tips

While Appian provides robust reporting and data visualization capabilities, it is not designed to be a replacement for commercial Business Intelligence tools, should that level of functionality be required.
When details about specific reports are not known or are unavailable, assumptions such as the number of reports and average complexity will simplify your estimation efforts.

5) Integrations

Appian connects to other systems utilizing Appian’s integration components.

Impact on Estimate

A large number of system integrations increases the complexity associated with testing and deployment.
Specialized integration requirements frequently cause delays and impact dependent functionality.
IT network teams need to establish the network connections and authentication mechanisms required for integrations.

Common Assumptions

All integrations use standard Appian integration components.

Pro Tips

Confirm that all integration points and relevant documentation for integration methods are available by the start of the project - Appian development moves quickly and poor planning leads to integration services not being available on time.
Ensure that the appropriate contacts and subject matter experts are assigned and engaged to perform connectivity and integration tests for each system
Confirm that test environments are available for each system prior to the start of the project.

6) Security Requirements

Requirements that define the level of access to the system, features and data.

Impact on Estimate

Extensive security requirements lead to more effort to design, build, test and deploy the solution:.

Complex authorization requirements:
- Maintaining authorization lists external to Appian: for example calling web-services to authorize access to data.
- Sourcing permissions from multiple locations or systems.
Complex data access control requirements:
- Requirements to manage access at different object levels: Application, Record Type, Record Instance, Data field level.
Large number of roles and groups required to manage functional access:
- Strict requirements for segregation of duties.
- Strict requirements for role level access.
- Strict regulatory needs to manage access.
Complex document access controls in Appian document store.

Common Assumptions

There is only one Authentication system.
Document access control can be configured utilizing Appian out-of-the-box functionality.
Access to the system, data and functionality in Appian are configured through Appian Groups.

Pro Tips

If exact details are not known, estimate the number of Roles and/or Groups in order to build the project estimate.

7) Outliers

Other factors that could affect the size of Appian projects.

Delivery Methodology - Agile preferred and recommended.
Self-managed vs Appian cloud - Appian cloud is preferred.
Regulatory Requirements - for example GxP for Pharmaceutical Companies.
IT Requirements - quality gates, deployment gates, go-live gates and support.

Impact on Estimate

Delivery Methodology - Agile delivery methodologies are particularly well suited for low-code application development. Other methodologies, such as waterfall, can be utilized successfully, but fail to capitalize on many advantages of the Appian low-code platform, ie. functionally complete and feature rich short build iterations, low cost of change, inherent robustness and fast time to production usage. If non-agile methodologies are utilized to deliver Appian projects, it might be prudent to account for longer delivery timelines for equivalent functionality.

Self-managed vs. Appian cloud - Self-managed installs of any tool introduces dependence on different internal teams for infrastructure, networking and maintenance. Appian cloud takes away most of these dependencies thereby reducing risk and potentially longer engagements.

Regulatory Requirements - All parts of a solution meeting regulatory requirements must usually adhere explicitly to the guidelines. This often requires additional functional and performance testing. Not all regulatory requirements negatively impact project size and complexity. Therefore an understanding of the requirements, how they affect architecture, design and testing is important to correctly judge the effect on the estimate.

IT Requirements - These are non-Appian platform specific requirements such as additional documentation needs, specific gate criteria for quality, specific deployment requirements etc. could have an impact on the overall size of the project. These must be understood and planned for.

Common Assumptions

The solution will be installed on Appian cloud.
Utilization of Agile delivery methodology, and the engagement of an empowered Product Owner, SMEs and Testers.
That all regulatory requirements are understood and explicitly communicated to the delivery team.
That all IT requirements are understood and explicitly communicated to the delivery team.

Estimation Templates

Indicative examples of project estimates are provided below.

Tags: Delivery, program management, Project Estimation

Writing to Synced Record Types at High Throughput

joel.larin — Thu, 18 Dec 2025 16:34:29 GMT

Current Revision posted to Guide by joel.larin on 12/18/2025 4:34:29 PM

Introduction

Appian's data fabric allows you to unify, secure, and optimize data spread across the enterprise. Typically, writing and syncing data in record types is as easy as using one of Appian’s smart services like Write Records, Write to Data Store Entity, and Write to Multiple Data Store Entities. However, when designing extremely high throughput autoscaled processes, you may need to modify your design to workaround write throughput limitations.

Synced record types are limited to handling up to ~30,000 write requests per minute for processes writing data in small batches (1-10 rows). Trying to sync data above this level of throughput will fail and can cause record type invalidations.

This guide explains how to design a process that supports writes to data fabric when peak times require more than ~30,000 write requests per minute across all of the applications on your site. This is accomplished through an incremental sync pattern where data is synced into the record types independently from the writes to the source table in large batches enabling over 1,000,000 rows to be synced per minute.

Example Process

Let’s say we have a process model with Autoscale enabled, which receives data over an API call, performs some transformations on the data, and then writes a single record to a synced record type.

Typically, the API is called only 200 to 300 times per minute. However, at peak times, the API is called over 30,000 times in a single minute. At these peak times, the Write Records node fails due to data sync limitations. Upon reaching data sync write throughput limitations, write performance will degrade, leading to request timeouts. Failed requests will return either 'could not obtain a reservation within the time limit' or 'the request has timed out due to the system being busy.'

Deferred Sync Pattern

In order to allow the process model to continue to process data even in times of peak load, we need to implement an independent sync pattern where data is synced in batches rather than one row at a time.

To avoid automatically syncing data to data fabric from the process model, an independent data store or a connected system data source must be created and used in the autoscaled process model to write data. This will allow us to write data only to the source table at first, and sync it in the record type independently.

Configure a New Data Source, Data Type, and Data Store

Create a new Data Source Connected System that connects to the same database as your existing record type.
Create a CDT from the table that already backs the synced record type.
Create a new data store with that CDT as an entity. Use the connected system data source you just created as the data source.

If your record type does not already have a modifiedOn timestamp, you will need to add that to your data structure, and ensure it is being updated every time the row is updated.

Replace the Write Records Node

In the autoscaled process model:

Update the process variable that holds the data being written to use a CDT instead of a record type (the one we just created). Update all usage of this variable.
Replace the Write Records node with a Write to Data Store Entity node, using a constant for the new data store we just created.
Click Save & Publish.

Now, your autoscaled process model will only write to the source table instead of automatically syncing data in the record type.

Sync Batches of Data Every 5 Minutes

After re-configuring the autoscaled model, create a separate process model running without autoscale enabled to incrementally sync data the record type from the source table.

To configure incremental sync:

Create a new process model without autoscale enabled.
Create process variables to track the timestamp at which data was last synced (lastSyncTime) and the list of IDs to sync (recordsToSync).
Set the default value of the lastSyncTime variable to now()-5. This will cause the first run of the process to sync anything updated after 5 minutes ago.
Configure a timer event on the start node to run the process every 5 minutes.

In a new expression rule, query the IDs of any rows modified after the lastSyncTime timestamp, using a query that looks like this:

a!queryEntity(
  entity: cons!JLT_RecordEntity,
  query: a!query(
    selection: a!querySelection(
      columns: {
        a!queryColumn(
          field: "id"
        )
      }
    ),
    logicalExpression: a!queryLogicalExpression(
      operator: "AND",
      filters: {
        a!queryFilter(
          field: "modifiedOn",
          operator: ">",
          value: ri!lastSyncTime
        )
      },
      ignoreFiltersWithEmptyValues: true
    ),
    pagingInfo: a!pagingInfo(
      startIndex: 1,
      batchSize: 50,
      sort: a!sortInfo(
        field: "modifiedOn",
        ascending: true
      )
    )
  ),
  fetchTotalCount: false
)

Add a Script Task to the process and call the expression rule created above, passing in lastSyncTime.
Add a Sync Records smart service node to sync the IDs you just queried in the record type. Since this will most likely require syncing more than 1000 rows at a time, you will need to use a loop to iterate over all rows that need to be synced.

That’s it! This pattern of ingesting data in larger batches can support syncing over 1,000,000 rows per minute in record types across all applications on your site, with data being updated in 5 minutes or less.

Tags: records, design patterns, Architecture, data fabric

Writing to Synced Record Types at High Throughput

joel.larin — Thu, 18 Dec 2025 16:33:43 GMT

Revision 34 posted to Guide by joel.larin on 12/18/2025 4:33:43 PM

Introduction

Trying to sync data above this level of throughput will fail and can cause record type invalidations.

Example Process

Let’s say we have a process model with Autoscale enabled, which receives data over an API call, performs some transformations on the data, and then writes a single record to a synced record type.

Deferred Sync Pattern

Configure a New Data Source, Data Type, and Data Store

Create a new Data Source Connected System that connects to the same database as your existing record type.
Create a CDT from the table that already backs the synced record type.
Create a new data store with that CDT as an entity. Use the connected system data source you just created as the data source.

If your record type does not already have a modifiedOn timestamp, you will need to add that to your data structure, and ensure it is being updated every time the row is updated.

Replace the Write Records Node

In the autoscaled process model:

Update the process variable that holds the data being written to use a CDT instead of a record type (the one we just created). Update all usage of this variable.
Replace the Write Records node with a Write to Data Store Entity node, using a constant for the new data store we just created.
Click Save & Publish.

Now, your autoscaled process model will only write to the source table instead of automatically syncing data in the record type.

Sync Batches of Data Every 5 Minutes

After re-configuring the autoscaled model, create a separate process model running without autoscale enabled to incrementally sync data the record type from the source table.

To configure incremental sync:

Create a new process model without autoscale enabled.
Create process variables to track the timestamp at which data was last synced (lastSyncTime) and the list of IDs to sync (recordsToSync).
Set the default value of the lastSyncTime variable to now()-5. This will cause the first run of the process to sync anything updated after 5 minutes ago.
Configure a timer event on the start node to run the process every 5 minutes.

In a new expression rule, query the IDs of any rows modified after the lastSyncTime timestamp, using a query that looks like this:

a!queryEntity(
  entity: cons!JLT_RecordEntity,
  query: a!query(
    selection: a!querySelection(
      columns: {
        a!queryColumn(
          field: "id"
        )
      }
    ),
    logicalExpression: a!queryLogicalExpression(
      operator: "AND",
      filters: {
        a!queryFilter(
          field: "modifiedOn",
          operator: ">",
          value: ri!lastSyncTime
        )
      },
      ignoreFiltersWithEmptyValues: true
    ),
    pagingInfo: a!pagingInfo(
      startIndex: 1,
      batchSize: 50,
      sort: a!sortInfo(
        field: "modifiedOn",
        ascending: true
      )
    )
  ),
  fetchTotalCount: false
)

Add a Script Task to the process and call the expression rule created above, passing in lastSyncTime.
Add a Sync Records smart service node to sync the IDs you just queried in the record type. Since this will most likely require syncing more than 1000 rows at a time, you will need to use a loop to iterate over all rows that need to be synced.

Tags: records, design patterns, Architecture, data fabric

Writing to Synced Record Types at High Throughput

joel.larin — Thu, 18 Dec 2025 16:31:32 GMT

Revision 33 posted to Guide by joel.larin on 12/18/2025 4:31:32 PM

Introduction

Appian's data fabric allows you to unify, secure, and optimize data spread across the enterprise. Typically, writing and syncing data in record types is as easy as using one of Appian’s smart services like Write Records, Write to Data Store Entity, and Write to Multiple Data Store Entities. However, when designing autoscaled processes, you may want to avoid using these smart services directly. Synced record types are limited to handling ~1,000 write requests per minute for processes writing data in small batches (1-10 rows).

Trying to sync data above this level of throughput will fail and can cause record type invalidations.

Example Process

Let’s say we have a process model with Autoscale enabled, which receives data over an API call, performs some transformations on the data, and then writes a single record to a synced record type.

Typically, the API is called only 200 to 300 times per minute. However, at peak times, the API is called over 10,000 times in a single minute. At these peak times, the Write Records node fails due to data sync limitations. Upon reaching data sync write throughput limitations, write performance will degrade, leading to request timeouts. Failed requests will return either 'could not obtain a reservation within the time limit' or 'the request has timed out due to the system being busy.'

Deferred Sync Pattern

Configure a New Data Source, Data Type, and Data Store

Create a new Data Source Connected System that connects to the same database as your existing record type.
Create a CDT from the table that already backs the synced record type.
Create a new data store with that CDT as an entity. Use the connected system data source you just created as the data source.

If your record type does not already have a modifiedOn timestamp, you will need to add that to your data structure, and ensure it is being updated every time the row is updated.

Replace the Write Records Node

In the autoscaled process model:

Update the process variable that holds the data being written to use a CDT instead of a record type (the one we just created). Update all usage of this variable.
Replace the Write Records node with a Write to Data Store Entity node, using a constant for the new data store we just created.
Click Save & Publish.

Now, your autoscaled process model will only write to the source table instead of automatically syncing data in the record type.

Sync Batches of Data Every 5 Minutes

After re-configuring the autoscaled model, create a separate process model running without autoscale enabled to incrementally sync data the record type from the source table.

To configure incremental sync:

Create a new process model without autoscale enabled.
Create process variables to track the timestamp at which data was last synced (lastSyncTime) and the list of IDs to sync (recordsToSync).
Set the default value of the lastSyncTime variable to now()-5. This will cause the first run of the process to sync anything updated after 5 minutes ago.
Configure a timer event on the start node to run the process every 5 minutes.

In a new expression rule, query the IDs of any rows modified after the lastSyncTime timestamp, using a query that looks like this:

a!queryEntity(
  entity: cons!JLT_RecordEntity,
  query: a!query(
    selection: a!querySelection(
      columns: {
        a!queryColumn(
          field: "id"
        )
      }
    ),
    logicalExpression: a!queryLogicalExpression(
      operator: "AND",
      filters: {
        a!queryFilter(
          field: "modifiedOn",
          operator: ">",
          value: ri!lastSyncTime
        )
      },
      ignoreFiltersWithEmptyValues: true
    ),
    pagingInfo: a!pagingInfo(
      startIndex: 1,
      batchSize: 50,
      sort: a!sortInfo(
        field: "modifiedOn",
        ascending: true
      )
    )
  ),
  fetchTotalCount: false
)

Add a Script Task to the process and call the expression rule created above, passing in lastSyncTime.
Add a Sync Records smart service node to sync the IDs you just queried in the record type. Since this will most likely require syncing more than 1000 rows at a time, you will need to use a loop to iterate over all rows that need to be synced.

That’s it! This pattern of ingesting data in larger batches can support syncing up to 200,000 rows per minute in record types across all applications on your site, with data being updated in 5 minutes or less.

Tags: records, design patterns, Architecture, data fabric

Automated Testing With Cucumber For Appian

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

Current Revision posted to Guide by joel.larin on 6/10/2025 11:23:50 PM

Cucumber For Appian is a client-side tool that builds on top of what FitNesse For Appian has implemented and allows users to write automated UI tests against Appian with Gherkin syntax. Cucumber For Appian will support all of the same fixture methods that FitNesse For Appian currently supports.

Requirements

Appian 22.2 and above
Java Runtime Environment 11
Chrome or Firefox browsers
If using Chrome, we recommend using Chrome For Testing for a more consistent testing experience.
Access to Terminal if you’re on Mac/Linux or Command Prompt if on Windows
Apache Maven tool

Installation

The zip file for the tool can be downloaded from the AppMarket.

Unzip the contents into any directory (e.g. C:/)
In a terminal window, navigate to the ‘CucumberForAppian-x’ (where x corresponds to the version number) folder extracted from the zip file (e.g. C:\CucumberForAppian-19.1-SNAPSHOT)
- We will refer to this directory as CUCUMBER_ROOT from now on

Running Cucumber Tests

Navigate to src/test/resources from CUCUMBER_ROOT
Edit either the ApplicationExample.feature or TempoNavigationExample.feature file
- “BROWSER” - Chrome or Firefox
- “APPIAN_URL” - e.g. https://site-name.appiancloud.com
- “APPIAN_VERSION” - e.g. 18.4
- “APPIAN_LOCALE” - en_US or en_GB
- “APPIAN_USERNAME” - e.g. fitnesse.user
- The comments on the top of the .feature files will also help you in setting up
- The completed feature file should look like the one shown below:

In CUCUMBER_ROOT, run ./setupCustomPropertiesForMac if using a mac or ./setupCustomPropertiesForLinux if using UNIX. If using Windows:
- Open the “custom.properties” file located in CUCUMBER_ROOT/src/main/resources/configs and modify:
  - automated.testing.home to be CUCUMBER_ROOT (e.g. C:\CucumberForAppian-19.1-SNAPSHOT)
  - download.directory to be CUCUMBER_ROOT/target (e.g. C:\CucumberForAppian-19.1-SNAPSHOT\target)
Run mvn clean test in CUCUMBER_ROOT
The output in the terminal should be similar to what’s displayed below

*NOTE* By default, only the TempoNavigationExample.feature test file will run when you execute the command above due to the “tags” argument in RunCucumberForAppianTest.java

At the top of the TempoNavigationExample.feature file, there is a tag “@Tempo” which corresponds to that in the .java file. To selectively run the tests, you can add or remove tags as you wish. You can completely remove the tags parameter if you’d like to run all of the tests together.

By default, the tool collects usage metrics for analytics purposes.

Developing Custom Cucumber tests

The Cucumber sample tests from above will be a good model to follow when developing your own tests.

To help you out, we have provided a CucumberForAppian Cheatsheet. You can find it individually in the combined files ZIP you downloaded from the App Market. When developing tests, be sure you are using methods for the environment you are testing. For example, if testing sites, use navigation methods that come from the "Sites Methods" scenario. Using methods from a different environment has the potential to break in future releases.

The CheatSheet.feature file lists out all the methods we support and how to invoke them using the @Given, @When, @Then, @But, @And.... and other Cucumber supported annotation

Features

Multiple browser support

Chrome (v64-66)
Firefox (v53-v62)

Benefits

Test your Appian application within minutes of downloading the tool
Methods created specifically to operate within Appian applications and Tempo
Test scripts do not need to be updated for upgrades to supported Appian versions
Appian design knowledge is not required to create test scripts
Common test case scenarios can be created for reusability throughout test suites
Test scripts are easily updated for new UI changes to a form or interface

Release Notes

March 2025 - Release 25.1

Enhancements
- Added support for defining and using custom locales. Use create appian locale | PATH TO File. This method must be called after setting the version.
  - File must be JSON file with the format: { "dateFormats": [ { "label": "dateFormat", "value": <FORMAT_STRING> }, { "label": "dateDisplayFormat", "value": <FORMAT_STRING> }, { "label": "timeFormat", "value": <FORMAT_STRING> }, { "label": "timeDisplayFormat", "value": <FORMAT_STRING> }, { "label": "datetimeFormat", "value": <FORMAT_STRING> }, { "label": "datetimeDisplayFormat","value": <FORMAT_STRING> } ], "labels": [ { "label": "acceptButton", "value": "Accept" } ], "locale": <LOCALE_CODE> }
Bug Fixes
- Fixed clickOnRecordRelatedAction to function correctly when the Record Summary page contains more than three action items.

August 2024 - Release 24.3

Enhancements
- Added built-in retry to click operation in case of element not interactable exception.
- Updated the milestone locator.

June 2024 - Release 24.2

Enhancements
- Updated locator for site menu links
- Created method which supports clicking on text within an interface. This is particularly useful for nested cards such as tab layouts, but can also be used as a fallback when existing methods don't work. This method is available for all Appian versions.
- Click operation on Card layout will be performed on the left side of the element instead of the right. We're not expecting any impact on existing test cases.

March 2024 - Release 24.1

Enhancements
- Support for Appian version 24.1
- Adds support for collapsing/opening sidebars
- ClickOnCard updated to support clicking on cards with complex content. For example, the method can now click on cards that have a component nested in multiple layouts within the card

November 2023 - Release 23.4

NOTE: Project has been updated to require Java 11 JRE
Enhancements
- Support for Appian version 23.4
- Add support for the side navigation menu in sites
- Add support for downloading charts
- Add support for buttons configured with custom colors
Bug Fixes
- Honor the download directory given in custom.properties for Remote Drivers
- Update dropdowns for versions greater than 23.3 to ignore the aria-checked value
- Fixed Populate Record Type Data Range User Filter method

August 2023 - Release 23.3

Enhancements
- Supports Appian version 23.3
- Added functionality to interact with new site group headers
- Updated to Selenium 4.11.0
- Add support for Date Range user filters in Record Types
- Update checkboxes to support CARD style for 23.3 and later Appian versions

June 2023 - Release 23.2.1

NOTE: Updates to site navigation in the 23.2 product breaks the use of the "click on menu" method in site environments. "click on menu", and other Tempo navigation methods, are guaranteed to work only in Tempo environments. Use the "click on site page" method instead
Bug Fixes
- Update pickers to recognize selections with links (e.g. Record Pickers)

June 2023 - Release 23.2

Enhancements
- Supports Appian version 23.2
  - NOTE: Updates to site navigation in the 23.2 product breaks the use of the "click on menu" method in site environments. "click on menu", and other Tempo navigation methods, are guaranteed to work only in Tempo environments. Use the "click on site page" method instead

May 2023 - Release 23.1.2

Bug Fixes
- Fixes an issue where Dropdowns with Search were not working
- Fixes an Issue where verifyText did not work on multi-node components

February 2023 - Release 23.1

Enhancements
- Supports Appian version 23.1
- Updated locator for Dropdown class
Bug Fixes
- Update CVEs
- Update scripts (start.bat, start-mac.sh, start-unix.sh, runFitNesseTest.sh) toreference the new fitnesse-20221219-standalone.jar

August 2022 - Release 22.3

Cucumber for Appian is released and supported
Removed support for 20.3

November 2021 - Release 21.4

Enhancements
- Support new card choice components
Bug Fixes
- Update CVEs

August 2021 - Release 21.3

Bug Fixes
- Fix bug for radio button card
- Fix bug for date picker

June 2021 - Release 21.2

Enhancements
- Support new SectionLayout
- Upgrade Selenium Server to 3.141.59
Bug Fixes
- Fix bug for radio button card
- Fix bug for icon link alt text

February 2021 - Release 21.1

Enhancements
- Supports Appian version 21.1

November 2020 - Release 20.4

Enhancements
- Support Chrome capabilities
- Update Cucumber to 6.8.2
- NEW METHOD: Support Stamp Field
- NEW METHOD: Support Tag field
- NEW METHOD: Support signature field
- NEW METHOD: Support record action field
Bug Fixes
- Fix grid row count bug when there is no paging
- Fix getGridColumnRowValue when the grid cell is a button
- Fix clear picker bug when there are multiple selections
- Fix capturing an empty rich text field

September 2020 - Release 20.3

Enhancements
- NEW METHOD: Populates the search box in a dropdown with some text
Bug fixes
- Fixed a bug for custom login submit button

August 2020 - Release 20.2.1

Bug Fixes
- Fixed a bug regarding clicking on card layouts

July 2020 - Release 20.2

Bug Fixes
- Fix bug with milestone click
- Fix toggle box visibility on related action pop up

April 2020 - Release 20.1

Enhancements
- NEW METHOD: click on bar chart *
- NEW METHOD: click on menu widget
- NEW METHOD: click on button with tooltip
- NEW METHOD: verify confirmation dialog header
- NEW METHOD: verify confirmation dialog message
- NEW METHOD: Verify a field is not blank
- NEW METHOD: click on document image link
- NEW METHOD: clear search field in record
- Include all jars in Cucumber
Bug fixes
- Remove pie chart hover for fragility and also make it the page scroll before hovering for firefox
- Clicking on standalone icons by making the xpath less specific
- Fix closing social task bug

January 2020 - Release 19.4.1

Enhancements
- NEW METHOD: star and unstar action with action name
- NEW METHOD: click on icon link with alt text
Bug fixes
- Fixed issues for dropdowns with many options

November 2019 - Release 19.4

Enhancements
- NEW METHOD: verify button with label is enabled
- NEW METHOD: verify button with label is disabled
- NEW METHOD: verify link containing text is not present
- NEW METHOD: verify a box with given label is present
- NEW METHOD: verify a box with given label is not present
- NEW METHOD: verify a section with given label is present
- NEW METHOD: verify a section with given label is not present
- NEW METHOD: verify a card with given accessibility text is present
- NEW METHOD: verify a card with given accessibility text is not present
- NEW METHOD: verify if text is not present anywhere in the user interface
Bug fixes
- Fixed populate first column in a grid when rowheader is set to 1

September 2019 - Release 19.3.1

Enhancements
- Added additional logging for site page navigation

Bug fixes
- Fixed verify text present for text with apostrophe

June 2019 - Release 19.2

Bug fixes
- Support sending news post without participants

May 2019 - Release 19.1.3

Bug fixes
- Fixed the bug that users can not click on menu tabs on Appian 19.1
- Fixed the bug on Read Only field "contains"
- Fixed the bug on sending news post on Appian 19.1

April 2019 - Release 19.1.2

Enhancements

Support Wait For Progress
Support Click on X and Y coordinates on monitor

Bug fixes

Fixed the bug that box layout toggle only acts on the first box

March 2019 - Release 19.1.1

Bug fixes

Fixed error popup caused by loading Automation Extension

February 2019 - Release 19.1

Cucumber For Appian available

Tags: testing, Architecture

Automated Testing With FitNesse for Appian

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

Revision 21 posted to Guide by joel.larin on 6/10/2025 11:23:43 PM

FitNesse for Appian provides an Appian-specific wiki language within FitNesse that maps directly to actions that can be performed in Appian, such as:

Navigating the interface (News, Tasks, Records, Reports, Actions, Sites)
Starting actions and completing tasks
Validating content on record views or in news events
And much more... the complete list is available directly within the tool!

For more information about testing and development best practices when using FitNesse for Appian, visit the FitNesse for Appian Best Practices guide.

Requirements

Appian 22.2 and above
Java Runtime Environment 11
Chrome or Firefox browsers
If using Chrome, we recommend using Chrome For Testing for a more consistent testing experience.

Setup

The zip file for the tool can be downloaded from the App Market Public Listings.

Unzip the contents into your root directory or preferred location (e.g. C:\)
In a terminal window navigate to the folder extracted from the zip file (e.g. C:\fitnesse-for-appian). We will refer to this directory as TESTING_HOME throughout this documentation
1. For PC, main commands will be:
  1. dir: used to show contents of current directory (folder)
  2. cd: used to change directory (open a folder), e.g. cd Documents would open the Documents folder. cd .. would go to the parent folder of current folder.
2. For Mac/Linux,
  1. ls: used to show contents of a directory (folder)
  2. cd: used to change directory (open a folder), e.g. cd Documents would open the Documents folder. cd .. would go to the parent folder of current folder.
Open the "custom.properties" file located in TESTING_HOME/configs and change:
1. automated.testing.home to be TESTING_HOME (e.g. C:\FitNesseForAppian)
2. download.directory to be a folder of your choosing
3. chrome.driver.home to be TESTING_HOME/lib/drivers/chromedriver(.exe if using windows, -mac if using a mac, -linux if using UNIX)
4. firefox.driver.home to be TESTING_HOME/lib/drivers/geckodriver(.exe if using windows, -mac if using a mac, -linux64 if using UNIX)
Run start.bat if using windows, start-mac.sh for Mac, and start-unix.sh for UNIX to install and run FitNesse for Appian. Installation should take around 30 seconds and is complete when you see the message "Starting FitNesse on port: 8980". To stop FitNesse for Appian, invoke Ctrl+C in the terminal.

Running your first FitNesse test

Start FitNesse if it isn't already running by running start.bat/start-mac.sh/start-unix.sh depending on your system
Navigate to http://localhost:8980/FitNesseForAppian.Examples.TestExample
Follow the configuration instructions marked by "Please follow the directions below to execute the test"
Click Test at the top of the page

Developing custom tests

To try out the tool further, use the Appian application included in the combined files download (Automated Testing - 1x.x.zip) and import it into your corresponding version of Appian environment.

An example test suite run could look like this:

By default, the tool collects usage metrics for analytics purposes. Set collect.metrics=false in the "metrics.properties" file to opt-out of metrics collection.

Features

Multiple browser support

Chrome (v64-66)
Firefox (v53-62)

Benefits

Test your Appian application within minutes of downloading the tool
Methods created specifically to operate within Appian applications and Tempo
Test scripts do not need to be updated for upgrades to supported Appian versions
Test scripts are written in a wiki language that is very easy to read and synthesize
Appian design knowledge is not required to create test scripts
Common case scenarios can be created for reusability throughout test suites
Isolate test steps into scenarios to perform Spec by Example tests
Test scripts are easily updated for new UI changes to a form or interface

Release Notes

March 2025 - Release 25.1

Enhancements
- Added support for defining and using custom locales. Use create appian locale | PATH TO File. This method must be called after setting the version.
  - File must be JSON file with the format: { "dateFormats": [ { "label": "dateFormat", "value": <FORMAT_STRING> }, { "label": "dateDisplayFormat", "value": <FORMAT_STRING> }, { "label": "timeFormat", "value": <FORMAT_STRING> }, { "label": "timeDisplayFormat", "value": <FORMAT_STRING> }, { "label": "datetimeFormat", "value": <FORMAT_STRING> }, { "label": "datetimeDisplayFormat","value": <FORMAT_STRING> } ], "labels": [ { "label": "acceptButton", "value": "Accept" } ], "locale": <LOCALE_CODE> }
Bug Fixes
- Fixed clickOnRecordRelatedAction to function correctly when the Record Summary page contains more than three action items.

August 2024 - Release 24.3

Enhancements
- Added built-in retry to click operation in case of element not interactable exception.
- Updated the milestone locator.

June 2024 - Release 24.2

Enhancements
- Updated locator for site menu links
- Created method which supports clicking on text within an interface. This is particularly useful for nested cards such as tab layouts, but can also be used as a fallback when existing methods don't work. This method is available for all Appian versions.
- Click operation on Card layout will be performed on the left side of the element instead of the right. We're not expecting any impact on existing test cases.

March 2024 - Release 24.1

Enhancements
- Support for Appian version 24.1
- Adds support for collapsing/opening sidebars
- ClickOnCard updated to support clicking on cards with complex content. For example, the method can now click on cards that have a component nested in multiple layouts within the card

November 2023 - Release 23.4

NOTE: Project has been updated to require Java 11 JRE
Enhancements
- Support for Appian version 23.4
- Add support for the side navigation menu in sites
- Add support for downloading charts
- Add support for buttons configured with custom colors
Bug Fixes
- Honor the download directory given in custom.properties for Remote Drivers
- Update dropdowns for versions greater than 23.3 to ignore the aria-checked value
- Fixed Populate Record Type Data Range User Filter method

August 2023 - Release 23.3

Enhancements
- Supports Appian version 23.3
- Added functionality to interact with new site group headers
- Updated to Selenium 4.11.0
- Add support for Date Range user filters in Record Types
- Update checkboxes to support CARD style for 23.3 and later Appian versions

June 2023 - Release 23.2.1

NOTE: Updates to site navigation in the 23.2 product breaks the use of the "click on menu" method in site environments. "click on menu", and other navigation methods from Tempo, are guaranteed to work only in Tempo environments. Use the "click on site page" method instead
Bug Fixes
- Update pickers to recognize selections with links (e.g. Record Pickers)

June 2023 - Release 23.2

Enhancements
- Supports Appian version 23.2
- NOTE: Updates to site navigation in the 23.2 product breaks the use of the "click on menu" method in site environments. "click on menu", and other navigation methods from Tempo, are guaranteed to work only in Tempo environments. Use the "click on site page" method instead

May 2023 - Release 23.1.2

Bug Fixes
- Fixes an issue where Dropdowns with Search were not working
- Fixes an Issue where verifyText did not work on multi-node components

February 2023 - Release 23.1

Enhancements
- Supports Appian version 23.1
- Updated locator for Dropdown class
Bug Fixes
- Update CVEs
- Update scripts (start.bat, start-mac.sh, start-unix.sh, runFitNesseTest.sh) toreference the new fitnesse-20221219-standalone.jar

August 2022 - Release 22.3

FitNesse for Appian is released and supported
Removed support for 20.3

November 2021 - Release 21.4

Enhancements
- Support new card choice components
Bug Fixes
- Update CVEs

August 2021 - Release 21.3

Bug Fixes
- Fix bug for radio button card
- Fix bug for date picker

June 2021 - Release 21.2

Enhancements
- Support new SectionLayout
- Upgrade Selenium Server to 3.141.59
Bug Fixes
- Fix bug for radio button card
- Fix bug for icon link alt text

February 2021 - Release 21.1

Enhancements
- Supports Appian version 21.1

November 2020 - Release 20.4

Enhancements
- Support Chrome capabilities
- Update FitNesse version to 20200501
- NEW METHOD: Support Stamp Field
- NEW METHOD: Support Tag field
- NEW METHOD: Support signature field
- NEW METHOD: Support record action field
Bug Fixes
- Fix grid row count bug when there is no paging
- Fix getGridColumnRowValue when the grid cell is a button
- Fix clear picker bug when there are multiple selections
- Fix capturing an empty rich text field

September 2020 - Release 20.3

Enhancements
- NEW METHOD: Populates the search box in a dropdown with some text
Bug Fixes
- Fixed a bug for custom login submit button

August 2020 - Release 20.2.1

Bug fixes
- Fixed a bug regarding clicking on card layouts

July 2020 - Release 20.2

Bug fixes
- Fix bug with milestone click
- Fix toggle box visibility on related action pop up

Apr 2020 - Release 20.1

Enhancements
- NEW METHOD: click on bar chart
- NEW METHOD: click on menu widget
- NEW METHOD: click on button with tooltip
- NEW METHOD: verify confirmation dialog header
- NEW METHOD: verify confirmation dialog message
- NEW METHOD: Verify a field is not blank
- NEW METHOD: click on document image link
- NEW METHOD: clear search field in record
Bug fixes
- Remove pie chart hover for fragility and also make it the page scroll before hovering for firefox
- Clicking on standalone icons by making the xpath less specific
- Fixed closing social task bug

January 2020 - Release 19.4.1

Enhancements
- NEW METHOD: star and unstar action with action name
- NEW METHOD: click on icon link with alt text
Bug fixes
- Fixed issues for dropdowns with many options

November 2019 - Release 19.4

Enhancements
- NEW METHOD: verify button with label is enabled
- NEW METHOD: verify button with label is disabled
- NEW METHOD: verify link containing text is not present
- NEW METHOD: verify a box with given label is present
- NEW METHOD: verify a box with given label is not present
- NEW METHOD: verify a section with given label is present
- NEW METHOD: verify a section with given label is not present
- NEW METHOD: verify a card with given accessibility text is present
- NEW METHOD: verify a card with given accessibility text is not present
- NEW METHOD: verify if text is not present anywhere in the user interface
Bug fixes
- Fixed populate first column in a grid when rowheader is set to 1

September 2019 - Release 19.3.1

Enhancements
- Added additional logging for site page navigation

Bug fixes
- Fixed verify text present for text with apostrophe

Sep 2019 - Release 19.3

Enhancements
- Support gauge field
- Support locating field using placeholder, instructions or tooltip
- NEW METHOD: get gauge field GAUGE_FIELD or GAUGE_FIELD[INDEX] percentage
- NEW METHOD: verify gauge field GAUGE_FIELD or GAUGE_FIELD[INDEX] percentage is PERCENTAGE
- NEW METHOD: populate field with placeholder PLACEHOLDER with VALUE(S)
- NEW METHOD: populate field with instructions INSTRUCTIONS with VALUE(S)
- NEW METHOD: populate field with tooltip TOOLTIP with VALUE(S)
- NEW METHOD: get field with placeholder PLACEHOLDER value
- NEW METHOD: get field with instructions INSTRUCTIONS value
- NEW METHOD: get field with tooltip TOOLTIP value
- NEW METHOD: verify field with placeholder PLACEHOLDER contains VALUE(S)
- NEW METHOD: verify field with instructions INSTRUCTIONS contains VALUE(S)
- NEW METHOD: verify field with tooltip TOOLTIP contains VALUE(S)

June 2019 - Release 19.2

Bug fixes
- Support sending news post without participants

May 2019 - Release 19.1.3

Bug fixes
- Fixed the bug that users can not click on menu tabs on Appian 19.1
- Fixed the bug on Read Only field "contains"
- Fixed the bug on sending news post on Appian 19.1

April 2019 - Release 19.1.2

Enhancements
- Support Wait For Progress
- Support Click on X and Y coordinates on monitor
Bug fixes
- Fixed the bug that box layout toggle only acts on the first box

March 2019 - Release 19.1.1

Bug fixes
- Fixed error popup caused by loading Automation Extension

February 2019 - Release 19.1

Enhancements
- Support Masked Barcode
- Support Vertical Milestone
Bug fixes
- Fixed login with terms for 17.2

January 2019 - Release 18.4.4

Enhancements
- NEW METHOD: populate field with partially matching picker field suggestion
- NEW METHOD: login into URL with username
- NEW METHOD: login into URL with role
- NEW METHOD: wait for seconds
- NEW METHOD: wait for minutes
- NEW METHOD: wait for working

January 2019 - Release 18.4.3

Enhancements
- Add capability to run tests on remote web drivers
Bug fixes
- Fixed milestone step verification
- Fixed section containing validation message verification

December 2018 - Release 18.4.2

Enhancements
- NEW METHOD: populate grid column row with partially matching picker field suggestion
- Other minor enhancements

November 2018 - Release 18.4.1

Enhancements
- Documentation overhaul
- Improved out of the box examples
- Updated information about supported Appian versions

October 2018 - Release 18.4

Enhancements
- NEW METHOD: open settings menu
- NEW METHOD: open user profile
- NEW METHOD: use discoverability to navigate to
- NEW METHOD: close social task
- NEW METHOD: verify task feed containing text is not present
- Added usage metrics and corresponding metrics.properties file
Bug Fixes
- Fixed login with terms

August 2018 - Release 18.3.1

Enhancements
- Added new methods for hovering and clicking on profile links and circles in news posts
Bug fixes
- Fixed NoClassDefFoundError for TempoEncryptedTextField introduced in 18.3

August 2018 - Release 18.3

Enhancements
- NEW METHOD: create a news post
- NEW METHOD: send kudos
- NEW METHOD: send messages
- NEW METHOD: send tasks
- NEW METHOD: sort tasks
- NEW METHOD: star a news feed item
- NEW METHOD: filter news feed
- NEW METHOD: navigate to link in news post
- NEW METHOD: generic assertion that text is present
Bug Fixes
- Fixed bug with MilestoneField pre-18.2
- Added WebContentField to 18.1

May 2018 - Release 18.2.1

Enhancements
- Auto login to previously set URL
- Milestones in side by side layout
- Card click identified by link name index
- NEW METHOD: verify video (not) present
- NEW METHOD: verify web content (not) present
- Updated test app for 18.2
Bug fixes
- User pickers not selecting correct field value
- Card click not working in Firefox

May 2018 - Release 18.2

Enhancements
- Added support for 18.2
- NEW METHOD: click on card
- Updated select grid method to account for the row highlight selection style
- Added test app for 18.2
Bug fixes
- Fixed fragility of file upload

March 2018 - Release 18.1.4

Enhancements
- Added Support for finding grid indices
- Added the ability to delete documents downloaded by Fitnesse

February 2018 - Release 18.1.3

Bug fixes
- Updated mac and linux scripts shebang to /bin/sh

February 2018 - Release 18.1.2

Bug fixes
- Fixed Windows start script to run FitNesse successfully
- Fixed the example page and default fixture to use TempoFixture instead of SitesFixture

January 2018 - Release 18.1.1

Enhancements
- Updated 16.3 Test Zip
Bug fixes
- Fixed issue with navigating to /logout URL
- Fixed Multiselect dropdown on 16.3
- Fixed Record filter clearing on 16.3

January 2018 - Release 18.1

Enhancements
- Added support for 18.1
- Added test app for 17.3 and 18.1

January 2018 - Release 17.4.1

Enhancements
- Add ability to accept Tasks
- Add ability to populate Record Type user filter
- Add ability to download files
- Make LinkField capturable
- Added advanced functionality to adjust dates, including setting dates in the past
- If url contains "/suite", remove anything after it to prevent navigation failure.
Bug fixes
- Updated chromedriver to version 2.33
- Updated startup scripts to pass FitNesseRoot properly
- Always logout before login in case a previous test failed and didn't logout
- Made Firefox webdrivers executable
- Fix BarcodeField not working in 17.1+

November 2017 - Release 17.4

Enhancement
- Change FitNesse usernames
- Allow FitNesse tests to hit an arbitrary endpoint through an environment variable
Bug fixes
- Mac Firefox date and dateTime field tests no longer throw an null character
- Dropdown tests does not read duplicate values

October 2017 - Release 17.3.2

Enhancements
- Updated test application to run initialize on import
Bug fixes
- Checkboxes that are too short are not checked

October 2017 - Release 17.3.1

Enhancements
- Updated Test App to create users
- Documentation tweaks/ Readme tweaks
Bug fixes
- Allowed login for internationalized pages
- Fixed an issue preventing searching in record list view
- Changed the way the start-unix script was sourced

September 2017 - Release 17.3

Enhancements
- Supports Appian version 17.3
- Ability to configure custom login page
- Updated the following components to be compatible with the latest Appian Hotfix Package for 17.1 (G), and 17.2 (D):
  - Paging Grid
  - Editable Grid
- Scripts now recognize new loading bar and wait for it to be done before continuing
- Added shell scripts and drivers for F4A on Mac and Linux
Bug fixes
- Browser is maximized by default which ensures the "Sign Out" button is always visibleNote: Previously tests could hang waiting to logout if the browser window was within a specific size range where the "Sign Out" button got hidden

Tags: testing, Platform, Architecture

Automated Testing with Appian Selenium API

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

Current Revision posted to Guide by joel.larin on 6/10/2025 11:23:25 PM

Requirements

Appian 22.2 and above
Java Runtime Environment 11
Chrome or Firefox browsers
If using Chrome, we recommend using Chrome For Testing for a more consistent testing experience.
An IDE, such as IntelliJ IDEA or Eclipse

Setup

The Appian Selenium API plug-in is a Java library which allows you to write automated tests for your Appian UIs. It contains methods which allow you to interact with Appian components in a browser. It provides methods and fixtures to interact with Appian applications in its various environments, e.g. Tempo or Sites. When writing tests, be sure to use methods from the correct fixture for the environment under test, e.g. use SitesFixture where possible to test Sites. Methods defined in fixtures that are intended for different environments are not guaranteed to work in future versions of the plugin.

It can be used in a Java application or integrated directly into any Selenium or Java-based testing tool.

Appian Selenium API contains the underlying Selenium methods used by Cucumber for Appian and FitNesse for Appian, but offers you more flexibility by allowing you to define your own automated test cases. You can create your own Cucumber Step Definitions, your own testNG test, or the Java Framework of your choosing. You are no longer tied to Cucumber for Appian or FitNesse for Appian yet you get the same ease and simplicity of those respective frameworks.

Open this project in an IDE, such as IntelliJ IDEA or Eclipse.
Update configurations:
1. Open file configs/custom.properties
  1. Update automated.testing.home with the path to this installation. Examples:
    1. Windows: automated.testing.home=C:\\testFolder\\appian-selenium-api-example-java
    2. Mac: automated.testing.home=/Users/tester/Desktop/appian-selenium-api-example-java
  2. Update chrome.driver.home with the path to the Chrome driver that comes with this installation. Examples: * Windows: automated.testing.home=C:\\testFolder\\appian-selenium-api-example-java\\lib\\drivers\\chromedriver.exe * Mac: automated.testing.home=/Users/tester/Desktop/appian-selenium-api-example-java/lib/drivers/chromedriver-mac
2. Open file configs/users.properties, for each username used in a test add a line in the format of <username>=<password> to this file.
  1. If you prefer not to disclose your password in plain text, you can also choose to use com.appiancorp.ps.automatedtest.fixture.BaseFixture.loginIntoWithUsernameAndPassword fixture method to login by passing in the password from a system property value.
Open "src/main/java/com/appiancorp/example/HelloAppian.java":
1. Update TEST_SITE_URL to your Appian URL, such as protected static String TEST_SITE_URL = "https://example.appiancloud.com/suite";
2. Update TEST_USERNAME with a username, such as protected static String TEST_USERNAME = "tester.tester"; * Make sure this user exists in configs/users.properties
Run the main() method of this class:
1. You should see that a Chrome browser will open up, and the fixture commands in HelloAppian.java will execute accordingly.
2. Note that this test will fail since your site might not have an action "Create a Case" under menu "Actions" that opens up an interface that has a "Submit" button.

Features

Multiple browser support

Chrome
Firefox

Benefits

Define your own integration tests without being limited by a third-party testing tool
Selenium-based test scripts can be created for reusability throughout test suites
Methods created specifically to operate within Appian applications and Tempo
Test scripts do not need to be updated when upgrading between supported Appian versions
Test scripts are easily updated for new UI changes to a form or interface
Appian design knowledge is not required to create test scripts

Release Notes

March 2025 - Release 25.1

Enhancements
- Added support for defining and using custom locales. Use create appian locale | PATH TO File. This method must be called after setting the version.
  - File must be JSON file with the format: { "dateFormats": [ { "label": "dateFormat", "value": <FORMAT_STRING> }, { "label": "dateDisplayFormat", "value": <FORMAT_STRING> }, { "label": "timeFormat", "value": <FORMAT_STRING> }, { "label": "timeDisplayFormat", "value": <FORMAT_STRING> }, { "label": "datetimeFormat", "value": <FORMAT_STRING> }, { "label": "datetimeDisplayFormat","value": <FORMAT_STRING> } ], "labels": [ { "label": "acceptButton", "value": "Accept" } ], "locale": <LOCALE_CODE> }
Bug Fixes
- Fixed clickOnRecordRelatedAction to function correctly when the Record Summary page contains more than three action items.

August 2024 - Release 24.3

Enhancements
- Added built-in retry to click operation in case of element not interactable exception.
- Updated the milestone locator.

June 2024 - Release 24.2

Enhancements
- Updated locator for site menu links
- Created method which supports clicking on text within an interface. This is particularly useful for nested cards such as tab layouts, but can also be used as a fallback when existing methods don't work. This method is available for all Appian versions.
- Click operation on Card layout will be performed on the left side of the element instead of the right. We're not expecting any impact on existing test cases.

March 2024 - Release 24.1

Enhancements
- Support for Appian version 24.1
- Adds support for collapsing/opening sidebars
- ClickOnCard updated to support clicking on cards with complex content. For example, the method can now click on cards that have a component nested in multiple layouts within the card

November 2023 - Release 23.4

NOTE: Project has been updated to require Java 11 JRE
Enhancements
- Support for Appian version 23.4
- Add support for the side navigation menu in sites
- Add support for downloading charts
- Add support for buttons configured with custom colors
Bug Fixes
- Honor the download directory given in custom.properties for Remote Drivers
- Update dropdowns for versions greater than 23.3 to ignore the aria-checked value
- Fixed Populate Record Type Data Range User Filter method

August 2023 - Release 23.3

NOTE: Project has been updated to require Java 11 JRE
Enhancements
- Supports Appian version 23.3
- Added functionality to interact with new site group headers
- Updated to Selenium 4.11.0
Bug Fixes
- Update checkboxes to support CARD style for 23.3 and later Appian versions

June 2023 - Release 23.2.1

NOTE: Updates to site navigation in the 23.2 product breaks the use of the clickOnMenu method defined in TempoFixtures for site environments. clickOnMenu, and other navigation methods defined in TempoFixtures, are guaranteed to work only in Tempo environments. Use the clickOnSitePage method defined in SitesFixtures instead
Bug Fixes
- Update pickers to recognize selections with links (e.g. Record Pickers)

June 2023 - Release 23.2

Enhancements
- Supports Appian version 23.2
  - NOTE: Updates to site navigation in the 23.2 product breaks the use of the clickOnMenu method defined in TempoFixtures for site environments. clickOnMenu, and other navigation methods defined in TempoFixtures, are guaranteed to work only in Tempo environments. Use the clickOnSitePage method defined in SitesFixtures instead

May 2023 - Release 23.1.2

Bug Fixes
- Fixes an issue where Dropdowns with Search were not working
- Fixes an Issue where verifyText did not work on multi-node components

February 2023 - Release 23.1

Enhancements
- Supports Appian version 23.1
- Updated locator for Dropdown class
Bug Fixes
- Update CVEs
- Update scripts (start.bat, start-mac.sh, start-unix.sh, runFitNesseTest.sh) to reference the new fitnesse-20221219-standalone.jar

August 2022 - Release 22.3

Appian Selenium API is released and supported
Removed support for 20.3

November 2021 - Release 21.4

Enhancements
- Support new card choice components
Bug Fixes
- Update CVEs

August 2021 - Release 21.3

Bug Fixes
- Fix bug for radio button card
- Fix bug for date picker

June 2021 - Release 21.2

Enhancements
- Support new SectionLayout
- Upgrade Selenium Server to 3.141.59
Bug Fixes
- Fix bug for radio button card
- Fix bug for icon link alt text

March 2021 - Release 21.1

Appian Selenium API is released and supported

Tags: testing, Architecture

Automated Testing With Cucumber For Appian

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

Revision 20 posted to Guide by joel.larin on 6/10/2025 11:22:12 PM

Requirements

Appian 22.2 and above
Java Runtime Environment 11
Chrome or Firefox browsers
If using Chrome, we recommend using Chrome For Testing for a more consistent testing experience.
Access to Terminal if you’re on Mac/Linux or Command Prompt if on Windows
Apache Maven tool

Installation

The zip file for the tool can be downloaded from the AppMarket.

Unzip the contents into any directory (e.g. C:/)
In a terminal window, navigate to the ‘CucumberForAppian-x’ (where x corresponds to the version number) folder extracted from the zip file (e.g. C:\CucumberForAppian-19.1-SNAPSHOT)
- We will refer to this directory as CUCUMBER_ROOT from now on

Running Cucumber Tests

Navigate to src/test/resources from CUCUMBER_ROOT
Edit either the ApplicationExample.feature or TempoNavigationExample.feature file
- “BROWSER” - Chrome or Firefox
- “APPIAN_URL” - e.g. https://site-name.appiancloud.com
- “APPIAN_VERSION” - e.g. 18.4
- “APPIAN_LOCALE” - en_US or en_GB
- “APPIAN_USERNAME” - e.g. fitnesse.user
- The comments on the top of the .feature files will also help you in setting up
- The completed feature file should look like the one shown below:

In CUCUMBER_ROOT, run ./setupCustomPropertiesForMac if using a mac or ./setupCustomPropertiesForLinux if using UNIX. If using Windows:
- Open the “custom.properties” file located in CUCUMBER_ROOT/src/main/resources/configs and modify:
  - automated.testing.home to be CUCUMBER_ROOT (e.g. C:\CucumberForAppian-19.1-SNAPSHOT)
  - download.directory to be CUCUMBER_ROOT/target (e.g. C:\CucumberForAppian-19.1-SNAPSHOT\target)
Run mvn clean test in CUCUMBER_ROOT
The output in the terminal should be similar to what’s displayed below

*NOTE* By default, only the TempoNavigationExample.feature test file will run when you execute the command above due to the “tags” argument in RunCucumberForAppianTest.java

By default, the tool collects usage metrics for analytics purposes.

Developing Custom Cucumber tests

The Cucumber sample tests from above will be a good model to follow when developing your own tests.

The CheatSheet.feature file lists out all the methods we support and how to invoke them using the @Given, @When, @Then, @But, @And.... and other Cucumber supported annotation

Features

Multiple browser support

Chrome (v64-66)
Firefox (v53-v62)

Benefits

Test your Appian application within minutes of downloading the tool
Methods created specifically to operate within Appian applications and Tempo
Test scripts do not need to be updated for upgrades to supported Appian versions
Appian design knowledge is not required to create test scripts
Common test case scenarios can be created for reusability throughout test suites
Test scripts are easily updated for new UI changes to a form or interface

Release Notes

March 2025 - Release 25.1

Enhancements
- Added support for defining and using custom locales. Use create appian locale | PATH TO File. This method must be called after setting the version.
  - File must be JSON file with the format: { "dateFormats": [ { "label": "dateFormat", "value": <FORMAT_STRING> }, { "label": "dateDisplayFormat", "value": <FORMAT_STRING> }, { "label": "timeFormat", "value": <FORMAT_STRING> }, { "label": "timeDisplayFormat", "value": <FORMAT_STRING> }, { "label": "datetimeFormat", "value": <FORMAT_STRING> }, { "label": "datetimeDisplayFormat","value": <FORMAT_STRING> } ], "labels": [ { "label": "acceptButton", "value": "Accept" } ], "locale": <LOCALE_CODE> }
Bug Fixes
- Fixed clickOnRecordRelatedAction to function correctly when the Record Summary page contains more than three action items.

August 2024 - Release 24.3

Enhancements
- Added built-in retry to click operation in case of element not interactable exception.
- Updated the milestone locator.

June 2024 - Release 24.2

Enhancements
- Updated locator for site menu links
- Created method which supports clicking on text within an interface. This is particularly useful for nested cards such as tab layouts, but can also be used as a fallback when existing methods don't work. This method is available for all Appian versions.
- Click operation on Card layout will be performed on the left side of the element instead of the right. We're not expecting any impact on existing test cases.

March 2024 - Release 24.1

Enhancements
- Support for Appian version 24.1
- Adds support for collapsing/opening sidebars
- ClickOnCard updated to support clicking on cards with complex content. For example, the method can now click on cards that have a component nested in multiple layouts within the card

November 2023 - Release 23.4

NOTE: Project has been updated to require Java 11 JRE
Enhancements
- Support for Appian version 23.4
- Add support for the side navigation menu in sites
- Add support for downloading charts
- Add support for buttons configured with custom colors
Bug Fixes
- Honor the download directory given in custom.properties for Remote Drivers
- Update dropdowns for versions greater than 23.3 to ignore the aria-checked value
- Fixed Populate Record Type Data Range User Filter method

August 2023 - Release 23.3

Enhancements
- Supports Appian version 23.3
- Added functionality to interact with new site group headers
- Updated to Selenium 4.11.0
- Add support for Date Range user filters in Record Types
- Update checkboxes to support CARD style for 23.3 and later Appian versions

June 2023 - Release 23.2.1

NOTE: Updates to site navigation in the 23.2 product breaks the use of the "click on menu" method in site environments. "click on menu", and other Tempo navigation methods, are guaranteed to work only in Tempo environments. Use the "click on site page" method instead
Bug Fixes
- Update pickers to recognize selections with links (e.g. Record Pickers)

June 2023 - Release 23.2

Enhancements
- Supports Appian version 23.2
  - NOTE: Updates to site navigation in the 23.2 product breaks the use of the "click on menu" method in site environments. "click on menu", and other Tempo navigation methods, are guaranteed to work only in Tempo environments. Use the "click on site page" method instead

May 2023 - Release 23.1.2

Bug Fixes
- Fixes an issue where Dropdowns with Search were not working
- Fixes an Issue where verifyText did not work on multi-node components

February 2023 - Release 23.1

Enhancements
- Supports Appian version 23.1
- Updated locator for Dropdown class
Bug Fixes
- Update CVEs
- Update scripts (start.bat, start-mac.sh, start-unix.sh, runFitNesseTest.sh) toreference the new fitnesse-20221219-standalone.jar

August 2022 - Release 22.3

Cucumber for Appian is released and supported
Removed support for 20.3

November 2021 - Release 21.4

Enhancements
- Support new card choice components
Bug Fixes
- Update CVEs

August 2021 - Release 21.3

Bug Fixes
- Fix bug for radio button card
- Fix bug for date picker

June 2021 - Release 21.2

Enhancements
- Support new SectionLayout
- Upgrade Selenium Server to 3.141.59
Bug Fixes
- Fix bug for radio button card
- Fix bug for icon link alt text

February 2021 - Release 21.1

Enhancements
- Supports Appian version 21.1

November 2020 - Release 20.4

Enhancements
- Support Chrome capabilities
- Update Cucumber to 6.8.2
- NEW METHOD: Support Stamp Field
- NEW METHOD: Support Tag field
- NEW METHOD: Support signature field
- NEW METHOD: Support record action field
Bug Fixes
- Fix grid row count bug when there is no paging
- Fix getGridColumnRowValue when the grid cell is a button
- Fix clear picker bug when there are multiple selections
- Fix capturing an empty rich text field

September 2020 - Release 20.3

Enhancements
- NEW METHOD: Populates the search box in a dropdown with some text
Bug fixes
- Fixed a bug for custom login submit button

August 2020 - Release 20.2.1

Bug Fixes
- Fixed a bug regarding clicking on card layouts

July 2020 - Release 20.2

Bug Fixes
- Fix bug with milestone click
- Fix toggle box visibility on related action pop up

April 2020 - Release 20.1

Enhancements
- NEW METHOD: click on bar chart *
- NEW METHOD: click on menu widget
- NEW METHOD: click on button with tooltip
- NEW METHOD: verify confirmation dialog header
- NEW METHOD: verify confirmation dialog message
- NEW METHOD: Verify a field is not blank
- NEW METHOD: click on document image link
- NEW METHOD: clear search field in record
- Include all jars in Cucumber
Bug fixes
- Remove pie chart hover for fragility and also make it the page scroll before hovering for firefox
- Clicking on standalone icons by making the xpath less specific
- Fix closing social task bug

January 2020 - Release 19.4.1

Enhancements
- NEW METHOD: star and unstar action with action name
- NEW METHOD: click on icon link with alt text
Bug fixes
- Fixed issues for dropdowns with many options

November 2019 - Release 19.4

Enhancements
- NEW METHOD: verify button with label is enabled
- NEW METHOD: verify button with label is disabled
- NEW METHOD: verify link containing text is not present
- NEW METHOD: verify a box with given label is present
- NEW METHOD: verify a box with given label is not present
- NEW METHOD: verify a section with given label is present
- NEW METHOD: verify a section with given label is not present
- NEW METHOD: verify a card with given accessibility text is present
- NEW METHOD: verify a card with given accessibility text is not present
- NEW METHOD: verify if text is not present anywhere in the user interface
Bug fixes
- Fixed populate first column in a grid when rowheader is set to 1

September 2019 - Release 19.3.1

Enhancements
- Added additional logging for site page navigation

Bug fixes
- Fixed verify text present for text with apostrophe

June 2019 - Release 19.2

Bug fixes
- Support sending news post without participants

May 2019 - Release 19.1.3

Bug fixes
- Fixed the bug that users can not click on menu tabs on Appian 19.1
- Fixed the bug on Read Only field "contains"
- Fixed the bug on sending news post on Appian 19.1

April 2019 - Release 19.1.2

Enhancements

Support Wait For Progress
Support Click on X and Y coordinates on monitor

Bug fixes

Fixed the bug that box layout toggle only acts on the first box

March 2019 - Release 19.1.1

Bug fixes

Fixed error popup caused by loading Automation Extension

February 2019 - Release 19.1

Cucumber For Appian available

Tags: testing, Architecture

Automated Testing With Cucumber For Appian

Appian Max Team — Wed, 05 Mar 2025 20:53:19 GMT

Revision 19 posted to Guide by Appian Max Team on 3/5/2025 8:53:19 PM

Requirements

Appian 22.2 and above
Java Runtime Environment 11
Chrome or Firefox browsers
If using Chrome, we recommend using Chrome For Testing for a more consistent testing experience.
Access to Terminal if you’re on Mac/Linux or Command Prompt if on Windows
Apache Maven tool

Installation

The zip file for the tool can be downloaded from the AppMarket.

Unzip the contents into any directory (e.g. C:/)
In a terminal window, navigate to the ‘CucumberForAppian-x’ (where x corresponds to the version number) folder extracted from the zip file (e.g. C:\CucumberForAppian-19.1-SNAPSHOT)
- We will refer to this directory as CUCUMBER_ROOT from now on

Running Cucumber Tests

Navigate to src/test/resources from CUCUMBER_ROOT
Edit either the ApplicationExample.feature or TempoNavigationExample.feature file
- “BROWSER” - Chrome or Firefox
- “APPIAN_URL” - e.g. https://site-name.appiancloud.com
- “APPIAN_VERSION” - e.g. 18.4
- “APPIAN_LOCALE” - en_US or en_GB
- “APPIAN_USERNAME” - e.g. fitnesse.user
- The comments on the top of the .feature files will also help you in setting up
- The completed feature file should look like the one shown below:

In CUCUMBER_ROOT, run ./setupCustomPropertiesForMac if using a mac or ./setupCustomPropertiesForLinux if using UNIX. If using Windows:
- Open the “custom.properties” file located in CUCUMBER_ROOT/src/main/resources/configs and modify:
  - automated.testing.home to be CUCUMBER_ROOT (e.g. C:\CucumberForAppian-19.1-SNAPSHOT)
  - download.directory to be CUCUMBER_ROOT/target (e.g. C:\CucumberForAppian-19.1-SNAPSHOT\target)
Run mvn clean test in CUCUMBER_ROOT
The output in the terminal should be similar to what’s displayed below

*NOTE* By default, only the TempoNavigationExample.feature test file will run when you execute the command above due to the “tags” argument in RunCucumberForAppianTest.java

By default, the tool collects usage metrics for analytics purposes.

Developing Custom Cucumber tests

The Cucumber sample tests from above will be a good model to follow when developing your own tests.

The CheatSheet.feature file lists out all the methods we support and how to invoke them using the @Given, @When, @Then, @But, @And.... and other Cucumber supported annotation

Features

Multiple browser support

Chrome (v64-66)
Firefox (v53-v62)

Benefits

Test your Appian application within minutes of downloading the tool
Methods created specifically to operate within Appian applications and Tempo
Test scripts do not need to be updated for upgrades to supported Appian versions
Appian design knowledge is not required to create test scripts
Common test case scenarios can be created for reusability throughout test suites
Test scripts are easily updated for new UI changes to a form or interface

Release Notes

March 2025 - Release 25.1

Enhancements
- Added support for defining and using custom locales. Use create appian locale | PATH TO File. This method must be called after setting the version.
  - File must be JSON file with the format: { "dateFormats": [ { "label": "dateFormat", "value": <FORMAT_STRING> }, { "label": "dateDisplayFormat", "value": <FORMAT_STRING> }, { "label": "timeFormat", "value": <FORMAT_STRING> }, { "label": "timeDisplayFormat", "value": <FORMAT_STRING> }, { "label": "datetimeFormat", "value": <FORMAT_STRING> }, { "label": "datetimeDisplayFormat","value": <FORMAT_STRING> } ], "labels": [ { "label": "acceptButton", "value": "Accept" } ], "locale": <LOCALE_CODE> }
Bug Fixes
- Fixed clickOnRecordRelatedAction to function correctly when the Record Summary page contains more than three action items.

August 2024 - Release 24.3

Enhancements
- Added built-in retry to click operation in case of element not interactable exception.
- Updated the milestone locator.

June 2024 - Release 24.2

Enhancements
- Updated locator for site menu links
- Created method which supports clicking on text within an interface. This is particularly useful for nested cards such as tab layouts, but can also be used as a fallback when existing methods don't work. This method is available for all Appian versions.
- Click operation on Card layout will be performed on the left side of the element instead of the right. We're not expecting any impact on existing test cases.

March 2024 - Release 24.1

Enhancements
- Support for Appian version 24.1
- Adds support for collapsing/opening sidebars
- ClickOnCard updated to support clicking on cards with complex content. For example, the method can now click on cards that have a component nested in multiple layouts within the card

November 2023 - Release 23.4

NOTE: Project has been updated to require Java 11 JRE
Enhancements
- Support for Appian version 23.4
- Add support for the side navigation menu in sites
- Add support for downloading charts
- Add support for buttons configured with custom colors
Bug Fixes
- Honor the download directory given in custom.properties for Remote Drivers
- Update dropdowns for versions greater than 23.3 to ignore the aria-checked value
- Fixed Populate Record Type Data Range User Filter method

August 2023 - Release 23.3

Enhancements
- Supports Appian version 23.3
- Added functionality to interact with new site group headers
- Updated to Selenium 4.11.0
- Add support for Date Range user filters in Record Types
- Update checkboxes to support CARD style for 23.3 and later Appian versions

June 2023 - Release 23.2.1

NOTE: Updates to site navigation in the 23.2 product breaks the use of the "click on menu" method in site environments. "click on menu", and other Tempo navigation methods, are guaranteed to work only in Tempo environments. Use the "click on site page" method instead
Bug Fixes
- Update pickers to recognize selections with links (e.g. Record Pickers)

June 2023 - Release 23.2

Enhancements
- Supports Appian version 23.2
  - NOTE: Updates to site navigation in the 23.2 product breaks the use of the "click on menu" method in site environments. "click on menu", and other Tempo navigation methods, are guaranteed to work only in Tempo environments. Use the "click on site page" method instead

May 2023 - Release 23.1.2

Bug Fixes
- Fixes an issue where Dropdowns with Search were not working
- Fixes an Issue where verifyText did not work on multi-node components

February 2023 - Release 23.1

Enhancements
- Supports Appian version 23.1
- Updated locator for Dropdown class
Bug Fixes
- Update CVEs
- Update scripts (start.bat, start-mac.sh, start-unix.sh, runFitNesseTest.sh) toreference the new fitnesse-20221219-standalone.jar

August 2022 - Release 22.3

Cucumber for Appian is released and supported
Removed support for 20.3

November 2021 - Release 21.4

Enhancements
- Support new card choice components
Bug Fixes
- Update CVEs

August 2021 - Release 21.3

Bug Fixes
- Fix bug for radio button card
- Fix bug for date picker

June 2021 - Release 21.2

Enhancements
- Support new SectionLayout
- Upgrade Selenium Server to 3.141.59
Bug Fixes
- Fix bug for radio button card
- Fix bug for icon link alt text

February 2021 - Release 21.1

Enhancements
- Supports Appian version 21.1

November 2020 - Release 20.4

Enhancements
- Support Chrome capabilities
- Update Cucumber to 6.8.2
- NEW METHOD: Support Stamp Field
- NEW METHOD: Support Tag field
- NEW METHOD: Support signature field
- NEW METHOD: Support record action field
Bug Fixes
- Fix grid row count bug when there is no paging
- Fix getGridColumnRowValue when the grid cell is a button
- Fix clear picker bug when there are multiple selections
- Fix capturing an empty rich text field

September 2020 - Release 20.3

Enhancements
- NEW METHOD: Populates the search box in a dropdown with some text
Bug fixes
- Fixed a bug for custom login submit button

August 2020 - Release 20.2.1

Bug Fixes
- Fixed a bug regarding clicking on card layouts

July 2020 - Release 20.2

Bug Fixes
- Fix bug with milestone click
- Fix toggle box visibility on related action pop up

April 2020 - Release 20.1

Enhancements
- NEW METHOD: click on bar chart *
- NEW METHOD: click on menu widget
- NEW METHOD: click on button with tooltip
- NEW METHOD: verify confirmation dialog header
- NEW METHOD: verify confirmation dialog message
- NEW METHOD: Verify a field is not blank
- NEW METHOD: click on document image link
- NEW METHOD: clear search field in record
- Include all jars in Cucumber
Bug fixes
- Remove pie chart hover for fragility and also make it the page scroll before hovering for firefox
- Clicking on standalone icons by making the xpath less specific
- Fix closing social task bug

January 2020 - Release 19.4.1

Enhancements
- NEW METHOD: star and unstar action with action name
- NEW METHOD: click on icon link with alt text
Bug fixes
- Fixed issues for dropdowns with many options

November 2019 - Release 19.4

Enhancements
- NEW METHOD: verify button with label is enabled
- NEW METHOD: verify button with label is disabled
- NEW METHOD: verify link containing text is not present
- NEW METHOD: verify a box with given label is present
- NEW METHOD: verify a box with given label is not present
- NEW METHOD: verify a section with given label is present
- NEW METHOD: verify a section with given label is not present
- NEW METHOD: verify a card with given accessibility text is present
- NEW METHOD: verify a card with given accessibility text is not present
- NEW METHOD: verify if text is not present anywhere in the user interface
Bug fixes
- Fixed populate first column in a grid when rowheader is set to 1

September 2019 - Release 19.3.1

Enhancements
- Added additional logging for site page navigation

Bug fixes
- Fixed verify text present for text with apostrophe

June 2019 - Release 19.2

Bug fixes
- Support sending news post without participants

May 2019 - Release 19.1.3

Bug fixes
- Fixed the bug that users can not click on menu tabs on Appian 19.1
- Fixed the bug on Read Only field "contains"
- Fixed the bug on sending news post on Appian 19.1

April 2019 - Release 19.1.2

Enhancements

Support Wait For Progress
Support Click on X and Y coordinates on monitor

Bug fixes

Fixed the bug that box layout toggle only acts on the first box

March 2019 - Release 19.1.1

Bug fixes

Fixed error popup caused by loading Automation Extension

February 2019 - Release 19.1

Cucumber For Appian available

Tags: testing, Architecture

Automated Testing With FitNesse for Appian

Appian Max Team — Wed, 05 Mar 2025 20:52:22 GMT

Revision 20 posted to Guide by Appian Max Team on 3/5/2025 8:52:22 PM

FitNesse for Appian provides an Appian-specific wiki language within FitNesse that maps directly to actions that can be performed in Appian, such as:

Navigating the interface (News, Tasks, Records, Reports, Actions, Sites)
Starting actions and completing tasks
Validating content on record views or in news events
And much more... the complete list is available directly within the tool!

For more information about testing and development best practices when using FitNesse for Appian, visit the FitNesse for Appian Best Practices guide.

Requirements

Appian 22.2 and above
Java Runtime Environment 11
Chrome or Firefox browsers
If using Chrome, we recommend using Chrome For Testing for a more consistent testing experience.

Setup

The zip file for the tool can be downloaded from the App Market Public Listings.

Unzip the contents into your root directory or preferred location (e.g. C:\)
In a terminal window navigate to the folder extracted from the zip file (e.g. C:\fitnesse-for-appian). We will refer to this directory as TESTING_HOME throughout this documentation
1. For PC, main commands will be:
  1. dir: used to show contents of current directory (folder)
  2. cd: used to change directory (open a folder), e.g. cd Documents would open the Documents folder. cd .. would go to the parent folder of current folder.
2. For Mac/Linux,
  1. ls: used to show contents of a directory (folder)
  2. cd: used to change directory (open a folder), e.g. cd Documents would open the Documents folder. cd .. would go to the parent folder of current folder.
Open the "custom.properties" file located in TESTING_HOME/configs and change:
1. automated.testing.home to be TESTING_HOME (e.g. C:\FitNesseForAppian)
2. download.directory to be a folder of your choosing
3. chrome.driver.home to be TESTING_HOME/lib/drivers/chromedriver(.exe if using windows, -mac if using a mac, -linux if using UNIX)
4. firefox.driver.home to be TESTING_HOME/lib/drivers/geckodriver(.exe if using windows, -mac if using a mac, -linux64 if using UNIX)
Run start.bat if using windows, start-mac.sh for Mac, and start-unix.sh for UNIX to install and run FitNesse for Appian. Installation should take around 30 seconds and is complete when you see the message "Starting FitNesse on port: 8980". To stop FitNesse for Appian, invoke Ctrl+C in the terminal.

Running your first FitNesse test

Start FitNesse if it isn't already running by running start.bat/start-mac.sh/start-unix.sh depending on your system
Navigate to http://localhost:8980/FitNesseForAppian.Examples.TestExample
Follow the configuration instructions marked by "Please follow the directions below to execute the test"
Click Test at the top of the page

Developing custom tests

To try out the tool further, use the Appian application included in the combined files download (Automated Testing - 1x.x.zip) and import it into your corresponding version of Appian environment.

An example test suite run could look like this:

By default, the tool collects usage metrics for analytics purposes. Set collect.metrics=false in the "metrics.properties" file to opt-out of metrics collection.

Features

Multiple browser support

Chrome (v64-66)
Firefox (v53-62)

Benefits

Test your Appian application within minutes of downloading the tool
Methods created specifically to operate within Appian applications and Tempo
Test scripts do not need to be updated for upgrades to supported Appian versions
Test scripts are written in a wiki language that is very easy to read and synthesize
Appian design knowledge is not required to create test scripts
Common case scenarios can be created for reusability throughout test suites
Isolate test steps into scenarios to perform Spec by Example tests
Test scripts are easily updated for new UI changes to a form or interface

Release Notes

March 2025 - Release 25.1

Enhancements
- Added support for defining and using custom locales. Use create appian locale | PATH TO File. This method must be called after setting the version.
  - File must be JSON file with the format: { "dateFormats": [ { "label": "dateFormat", "value": <FORMAT_STRING> }, { "label": "dateDisplayFormat", "value": <FORMAT_STRING> }, { "label": "timeFormat", "value": <FORMAT_STRING> }, { "label": "timeDisplayFormat", "value": <FORMAT_STRING> }, { "label": "datetimeFormat", "value": <FORMAT_STRING> }, { "label": "datetimeDisplayFormat","value": <FORMAT_STRING> } ], "labels": [ { "label": "acceptButton", "value": "Accept" } ], "locale": <LOCALE_CODE> }
Bug Fixes
- Fixed clickOnRecordRelatedAction to function correctly when the Record Summary page contains more than three action items.

August 2024 - Release 24.3

Enhancements
- Added built-in retry to click operation in case of element not interactable exception.
- Updated the milestone locator.

June 2024 - Release 24.2

Enhancements
- Updated locator for site menu links
- Created method which supports clicking on text within an interface. This is particularly useful for nested cards such as tab layouts, but can also be used as a fallback when existing methods don't work. This method is available for all Appian versions.
- Click operation on Card layout will be performed on the left side of the element instead of the right. We're not expecting any impact on existing test cases.

March 2024 - Release 24.1

Enhancements
- Support for Appian version 24.1
- Adds support for collapsing/opening sidebars
- ClickOnCard updated to support clicking on cards with complex content. For example, the method can now click on cards that have a component nested in multiple layouts within the card

November 2023 - Release 23.4

NOTE: Project has been updated to require Java 11 JRE
Enhancements
- Support for Appian version 23.4
- Add support for the side navigation menu in sites
- Add support for downloading charts
- Add support for buttons configured with custom colors
Bug Fixes
- Honor the download directory given in custom.properties for Remote Drivers
- Update dropdowns for versions greater than 23.3 to ignore the aria-checked value
- Fixed Populate Record Type Data Range User Filter method

August 2023 - Release 23.3

Enhancements
- Supports Appian version 23.3
- Added functionality to interact with new site group headers
- Updated to Selenium 4.11.0
- Add support for Date Range user filters in Record Types
- Update checkboxes to support CARD style for 23.3 and later Appian versions

June 2023 - Release 23.2.1

NOTE: Updates to site navigation in the 23.2 product breaks the use of the "click on menu" method in site environments. "click on menu", and other navigation methods from Tempo, are guaranteed to work only in Tempo environments. Use the "click on site page" method instead
Bug Fixes
- Update pickers to recognize selections with links (e.g. Record Pickers)

June 2023 - Release 23.2

Enhancements
- Supports Appian version 23.2
- NOTE: Updates to site navigation in the 23.2 product breaks the use of the "click on menu" method in site environments. "click on menu", and other navigation methods from Tempo, are guaranteed to work only in Tempo environments. Use the "click on site page" method instead

May 2023 - Release 23.1.2

Bug Fixes
- Fixes an issue where Dropdowns with Search were not working
- Fixes an Issue where verifyText did not work on multi-node components

February 2023 - Release 23.1

Enhancements
- Supports Appian version 23.1
- Updated locator for Dropdown class
Bug Fixes
- Update CVEs
- Update scripts (start.bat, start-mac.sh, start-unix.sh, runFitNesseTest.sh) toreference the new fitnesse-20221219-standalone.jar

August 2022 - Release 22.3

FitNesse for Appian is released and supported
Removed support for 20.3

November 2021 - Release 21.4

Enhancements
- Support new card choice components
Bug Fixes
- Update CVEs

August 2021 - Release 21.3

Bug Fixes
- Fix bug for radio button card
- Fix bug for date picker

June 2021 - Release 21.2

Enhancements
- Support new SectionLayout
- Upgrade Selenium Server to 3.141.59
Bug Fixes
- Fix bug for radio button card
- Fix bug for icon link alt text

February 2021 - Release 21.1

Enhancements
- Supports Appian version 21.1

November 2020 - Release 20.4

Enhancements
- Support Chrome capabilities
- Update FitNesse version to 20200501
- NEW METHOD: Support Stamp Field
- NEW METHOD: Support Tag field
- NEW METHOD: Support signature field
- NEW METHOD: Support record action field
Bug Fixes
- Fix grid row count bug when there is no paging
- Fix getGridColumnRowValue when the grid cell is a button
- Fix clear picker bug when there are multiple selections
- Fix capturing an empty rich text field

September 2020 - Release 20.3

Enhancements
- NEW METHOD: Populates the search box in a dropdown with some text
Bug Fixes
- Fixed a bug for custom login submit button

August 2020 - Release 20.2.1

Bug fixes
- Fixed a bug regarding clicking on card layouts

July 2020 - Release 20.2

Bug fixes
- Fix bug with milestone click
- Fix toggle box visibility on related action pop up

Apr 2020 - Release 20.1

Enhancements
- NEW METHOD: click on bar chart
- NEW METHOD: click on menu widget
- NEW METHOD: click on button with tooltip
- NEW METHOD: verify confirmation dialog header
- NEW METHOD: verify confirmation dialog message
- NEW METHOD: Verify a field is not blank
- NEW METHOD: click on document image link
- NEW METHOD: clear search field in record
Bug fixes
- Remove pie chart hover for fragility and also make it the page scroll before hovering for firefox
- Clicking on standalone icons by making the xpath less specific
- Fixed closing social task bug

January 2020 - Release 19.4.1

Enhancements
- NEW METHOD: star and unstar action with action name
- NEW METHOD: click on icon link with alt text
Bug fixes
- Fixed issues for dropdowns with many options

November 2019 - Release 19.4

Enhancements
- NEW METHOD: verify button with label is enabled
- NEW METHOD: verify button with label is disabled
- NEW METHOD: verify link containing text is not present
- NEW METHOD: verify a box with given label is present
- NEW METHOD: verify a box with given label is not present
- NEW METHOD: verify a section with given label is present
- NEW METHOD: verify a section with given label is not present
- NEW METHOD: verify a card with given accessibility text is present
- NEW METHOD: verify a card with given accessibility text is not present
- NEW METHOD: verify if text is not present anywhere in the user interface
Bug fixes
- Fixed populate first column in a grid when rowheader is set to 1

September 2019 - Release 19.3.1

Enhancements
- Added additional logging for site page navigation

Bug fixes
- Fixed verify text present for text with apostrophe

Sep 2019 - Release 19.3

Enhancements
- Support gauge field
- Support locating field using placeholder, instructions or tooltip
- NEW METHOD: get gauge field GAUGE_FIELD or GAUGE_FIELD[INDEX] percentage
- NEW METHOD: verify gauge field GAUGE_FIELD or GAUGE_FIELD[INDEX] percentage is PERCENTAGE
- NEW METHOD: populate field with placeholder PLACEHOLDER with VALUE(S)
- NEW METHOD: populate field with instructions INSTRUCTIONS with VALUE(S)
- NEW METHOD: populate field with tooltip TOOLTIP with VALUE(S)
- NEW METHOD: get field with placeholder PLACEHOLDER value
- NEW METHOD: get field with instructions INSTRUCTIONS value
- NEW METHOD: get field with tooltip TOOLTIP value
- NEW METHOD: verify field with placeholder PLACEHOLDER contains VALUE(S)
- NEW METHOD: verify field with instructions INSTRUCTIONS contains VALUE(S)
- NEW METHOD: verify field with tooltip TOOLTIP contains VALUE(S)

June 2019 - Release 19.2

Bug fixes
- Support sending news post without participants

May 2019 - Release 19.1.3

Bug fixes
- Fixed the bug that users can not click on menu tabs on Appian 19.1
- Fixed the bug on Read Only field "contains"
- Fixed the bug on sending news post on Appian 19.1

April 2019 - Release 19.1.2

Enhancements
- Support Wait For Progress
- Support Click on X and Y coordinates on monitor
Bug fixes
- Fixed the bug that box layout toggle only acts on the first box

March 2019 - Release 19.1.1

Bug fixes
- Fixed error popup caused by loading Automation Extension

February 2019 - Release 19.1

Enhancements
- Support Masked Barcode
- Support Vertical Milestone
Bug fixes
- Fixed login with terms for 17.2

January 2019 - Release 18.4.4

Enhancements
- NEW METHOD: populate field with partially matching picker field suggestion
- NEW METHOD: login into URL with username
- NEW METHOD: login into URL with role
- NEW METHOD: wait for seconds
- NEW METHOD: wait for minutes
- NEW METHOD: wait for working

January 2019 - Release 18.4.3

Enhancements
- Add capability to run tests on remote web drivers
Bug fixes
- Fixed milestone step verification
- Fixed section containing validation message verification

December 2018 - Release 18.4.2

Enhancements
- NEW METHOD: populate grid column row with partially matching picker field suggestion
- Other minor enhancements

November 2018 - Release 18.4.1

Enhancements
- Documentation overhaul
- Improved out of the box examples
- Updated information about supported Appian versions

October 2018 - Release 18.4

Enhancements
- NEW METHOD: open settings menu
- NEW METHOD: open user profile
- NEW METHOD: use discoverability to navigate to
- NEW METHOD: close social task
- NEW METHOD: verify task feed containing text is not present
- Added usage metrics and corresponding metrics.properties file
Bug Fixes
- Fixed login with terms

August 2018 - Release 18.3.1

Enhancements
- Added new methods for hovering and clicking on profile links and circles in news posts
Bug fixes
- Fixed NoClassDefFoundError for TempoEncryptedTextField introduced in 18.3

August 2018 - Release 18.3

Enhancements
- NEW METHOD: create a news post
- NEW METHOD: send kudos
- NEW METHOD: send messages
- NEW METHOD: send tasks
- NEW METHOD: sort tasks
- NEW METHOD: star a news feed item
- NEW METHOD: filter news feed
- NEW METHOD: navigate to link in news post
- NEW METHOD: generic assertion that text is present
Bug Fixes
- Fixed bug with MilestoneField pre-18.2
- Added WebContentField to 18.1

May 2018 - Release 18.2.1

Enhancements
- Auto login to previously set URL
- Milestones in side by side layout
- Card click identified by link name index
- NEW METHOD: verify video (not) present
- NEW METHOD: verify web content (not) present
- Updated test app for 18.2
Bug fixes
- User pickers not selecting correct field value
- Card click not working in Firefox

May 2018 - Release 18.2

Enhancements
- Added support for 18.2
- NEW METHOD: click on card
- Updated select grid method to account for the row highlight selection style
- Added test app for 18.2
Bug fixes
- Fixed fragility of file upload

March 2018 - Release 18.1.4

Enhancements
- Added Support for finding grid indices
- Added the ability to delete documents downloaded by Fitnesse

February 2018 - Release 18.1.3

Bug fixes
- Updated mac and linux scripts shebang to /bin/sh

February 2018 - Release 18.1.2

Bug fixes
- Fixed Windows start script to run FitNesse successfully
- Fixed the example page and default fixture to use TempoFixture instead of SitesFixture

January 2018 - Release 18.1.1

Enhancements
- Updated 16.3 Test Zip
Bug fixes
- Fixed issue with navigating to /logout URL
- Fixed Multiselect dropdown on 16.3
- Fixed Record filter clearing on 16.3

January 2018 - Release 18.1

Enhancements
- Added support for 18.1
- Added test app for 17.3 and 18.1

January 2018 - Release 17.4.1

Enhancements
- Add ability to accept Tasks
- Add ability to populate Record Type user filter
- Add ability to download files
- Make LinkField capturable
- Added advanced functionality to adjust dates, including setting dates in the past
- If url contains "/suite", remove anything after it to prevent navigation failure.
Bug fixes
- Updated chromedriver to version 2.33
- Updated startup scripts to pass FitNesseRoot properly
- Always logout before login in case a previous test failed and didn't logout
- Made Firefox webdrivers executable
- Fix BarcodeField not working in 17.1+

November 2017 - Release 17.4

Enhancement
- Change FitNesse usernames
- Allow FitNesse tests to hit an arbitrary endpoint through an environment variable
Bug fixes
- Mac Firefox date and dateTime field tests no longer throw an null character
- Dropdown tests does not read duplicate values

October 2017 - Release 17.3.2

Enhancements
- Updated test application to run initialize on import
Bug fixes
- Checkboxes that are too short are not checked

October 2017 - Release 17.3.1

Enhancements
- Updated Test App to create users
- Documentation tweaks/ Readme tweaks
Bug fixes
- Allowed login for internationalized pages
- Fixed an issue preventing searching in record list view
- Changed the way the start-unix script was sourced

September 2017 - Release 17.3

Enhancements
- Supports Appian version 17.3
- Ability to configure custom login page
- Updated the following components to be compatible with the latest Appian Hotfix Package for 17.1 (G), and 17.2 (D):
  - Paging Grid
  - Editable Grid
- Scripts now recognize new loading bar and wait for it to be done before continuing
- Added shell scripts and drivers for F4A on Mac and Linux
Bug fixes
- Browser is maximized by default which ensures the "Sign Out" button is always visibleNote: Previously tests could hang waiting to logout if the browser window was within a specific size range where the "Sign Out" button got hidden

Tags: testing, Platform, Architecture

Automated Testing with Appian Selenium API

Appian Max Team — Wed, 05 Mar 2025 20:51:00 GMT

Revision 34 posted to Guide by Appian Max Team on 3/5/2025 8:51:00 PM

Requirements

Appian 22.2 and above
Java Runtime Environment 11
Chrome or Firefox browsers
If using Chrome, we recommend using Chrome For Testing for a more consistent testing experience.
An IDE, such as IntelliJ IDEA or Eclipse

Setup

It can be used in a Java application or integrated directly into any Selenium or Java-based testing tool.

Open this project in an IDE, such as IntelliJ IDEA or Eclipse.
Update configurations:
1. Open file configs/custom.properties
  1. Update automated.testing.home with the path to this installation. Examples:
    1. Windows: automated.testing.home=C:\\testFolder\\appian-selenium-api-example-java
    2. Mac: automated.testing.home=/Users/tester/Desktop/appian-selenium-api-example-java
  2. Update chrome.driver.home with the path to the Chrome driver that comes with this installation. Examples: * Windows: automated.testing.home=C:\\testFolder\\appian-selenium-api-example-java\\lib\\drivers\\chromedriver.exe * Mac: automated.testing.home=/Users/tester/Desktop/appian-selenium-api-example-java/lib/drivers/chromedriver-mac
2. Open file configs/users.properties, for each username used in a test add a line in the format of <username>=<password> to this file.
  1. If you prefer not to disclose your password in plain text, you can also choose to use com.appiancorp.ps.automatedtest.fixture.BaseFixture.loginIntoWithUsernameAndPassword fixture method to login by passing in the password from a system property value.
Open "src/main/java/com/appiancorp/example/HelloAppian.java":
1. Update TEST_SITE_URL to your Appian URL, such as protected static String TEST_SITE_URL = "https://example.appiancloud.com/suite";
2. Update TEST_USERNAME with a username, such as protected static String TEST_USERNAME = "tester.tester"; * Make sure this user exists in configs/users.properties
Run the main() method of this class:
1. You should see that a Chrome browser will open up, and the fixture commands in HelloAppian.java will execute accordingly.
2. Note that this test will fail since your site might not have an action "Create a Case" under menu "Actions" that opens up an interface that has a "Submit" button.

Features

Multiple browser support

Chrome
Firefox

Benefits

Define your own integration tests without being limited by a third-party testing tool
Selenium-based test scripts can be created for reusability throughout test suites
Methods created specifically to operate within Appian applications and Tempo
Test scripts do not need to be updated when upgrading between supported Appian versions
Test scripts are easily updated for new UI changes to a form or interface
Appian design knowledge is not required to create test scripts

Release Notes

March 2025 - Release 25.1

Enhancements
- Added support for defining and using custom locales. Use create appian locale | PATH TO File. This method must be called after setting the version.
  - File must be JSON file with the format: { "dateFormats": [ { "label": "dateFormat", "value": <FORMAT_STRING> }, { "label": "dateDisplayFormat", "value": <FORMAT_STRING> }, { "label": "timeFormat", "value": <FORMAT_STRING> }, { "label": "timeDisplayFormat", "value": <FORMAT_STRING> }, { "label": "datetimeFormat", "value": <FORMAT_STRING> }, { "label": "datetimeDisplayFormat","value": <FORMAT_STRING> } ], "labels": [ { "label": "acceptButton", "value": "Accept" } ], "locale": <LOCALE_CODE> }
Bug Fixes
- Fixed clickOnRecordRelatedAction to function correctly when the Record Summary page contains more than three action items.

August 2024 - Release 24.3

Enhancements
- Added built-in retry to click operation in case of element not interactable exception.
- Updated the milestone locator.

June 2024 - Release 24.2

Enhancements
- Updated locator for site menu links
- Created method which supports clicking on text within an interface. This is particularly useful for nested cards such as tab layouts, but can also be used as a fallback when existing methods don't work. This method is available for all Appian versions.
- Click operation on Card layout will be performed on the left side of the element instead of the right. We're not expecting any impact on existing test cases.

March 2024 - Release 24.1

Enhancements
- Support for Appian version 24.1
- Adds support for collapsing/opening sidebars
- ClickOnCard updated to support clicking on cards with complex content. For example, the method can now click on cards that have a component nested in multiple layouts within the card

November 2023 - Release 23.4

NOTE: Project has been updated to require Java 11 JRE
Enhancements
- Support for Appian version 23.4
- Add support for the side navigation menu in sites
- Add support for downloading charts
- Add support for buttons configured with custom colors
Bug Fixes
- Honor the download directory given in custom.properties for Remote Drivers
- Update dropdowns for versions greater than 23.3 to ignore the aria-checked value
- Fixed Populate Record Type Data Range User Filter method

August 2023 - Release 23.3

NOTE: Project has been updated to require Java 11 JRE
Enhancements
- Supports Appian version 23.3
- Added functionality to interact with new site group headers
- Updated to Selenium 4.11.0
Bug Fixes
- Update checkboxes to support CARD style for 23.3 and later Appian versions

June 2023 - Release 23.2.1

NOTE: Updates to site navigation in the 23.2 product breaks the use of the clickOnMenu method defined in TempoFixtures for site environments. clickOnMenu, and other navigation methods defined in TempoFixtures, are guaranteed to work only in Tempo environments. Use the clickOnSitePage method defined in SitesFixtures instead
Bug Fixes
- Update pickers to recognize selections with links (e.g. Record Pickers)

June 2023 - Release 23.2

Enhancements
- Supports Appian version 23.2
  - NOTE: Updates to site navigation in the 23.2 product breaks the use of the clickOnMenu method defined in TempoFixtures for site environments. clickOnMenu, and other navigation methods defined in TempoFixtures, are guaranteed to work only in Tempo environments. Use the clickOnSitePage method defined in SitesFixtures instead

May 2023 - Release 23.1.2

Bug Fixes
- Fixes an issue where Dropdowns with Search were not working
- Fixes an Issue where verifyText did not work on multi-node components

February 2023 - Release 23.1

Enhancements
- Supports Appian version 23.1
- Updated locator for Dropdown class
Bug Fixes
- Update CVEs
- Update scripts (start.bat, start-mac.sh, start-unix.sh, runFitNesseTest.sh) to reference the new fitnesse-20221219-standalone.jar

August 2022 - Release 22.3

Appian Selenium API is released and supported
Removed support for 20.3

November 2021 - Release 21.4

Enhancements
- Support new card choice components
Bug Fixes
- Update CVEs

August 2021 - Release 21.3

Bug Fixes
- Fix bug for radio button card
- Fix bug for date picker

June 2021 - Release 21.2

Enhancements
- Support new SectionLayout
- Upgrade Selenium Server to 3.141.59
Bug Fixes
- Fix bug for radio button card
- Fix bug for icon link alt text

March 2021 - Release 21.1

Appian Selenium API is released and supported

Tags: testing, Architecture

Automated Testing with Appian Selenium API

Appian Max Team — Wed, 05 Mar 2025 20:48:14 GMT

Revision 33 posted to Guide by Appian Max Team on 3/5/2025 8:48:14 PM

Requirements

Appian 22.2 and above
Java Runtime Environment 11
Chrome or Firefox browsers
If using Chrome, we recommend using Chrome For Testing for a more consistent testing experience.
An IDE, such as IntelliJ IDEA or Eclipse

Setup

It can be used in a Java application or integrated directly into any Selenium or Java-based testing tool.

Open this project in an IDE, such as IntelliJ IDEA or Eclipse.
Update configurations:
1. Open file configs/custom.properties
  1. Update automated.testing.home with the path to this installation. Examples:
    1. Windows: automated.testing.home=C:\\testFolder\\appian-selenium-api-example-java
    2. Mac: automated.testing.home=/Users/tester/Desktop/appian-selenium-api-example-java
  2. Update chrome.driver.home with the path to the Chrome driver that comes with this installation. Examples: * Windows: automated.testing.home=C:\\testFolder\\appian-selenium-api-example-java\\lib\\drivers\\chromedriver.exe * Mac: automated.testing.home=/Users/tester/Desktop/appian-selenium-api-example-java/lib/drivers/chromedriver-mac
2. Open file configs/users.properties, for each username used in a test add a line in the format of <username>=<password> to this file.
  1. If you prefer not to disclose your password in plain text, you can also choose to use com.appiancorp.ps.automatedtest.fixture.BaseFixture.loginIntoWithUsernameAndPassword fixture method to login by passing in the password from a system property value.
Open "src/main/java/com/appiancorp/example/HelloAppian.java":
1. Update TEST_SITE_URL to your Appian URL, such as protected static String TEST_SITE_URL = "https://example.appiancloud.com/suite";
2. Update TEST_USERNAME with a username, such as protected static String TEST_USERNAME = "tester.tester"; * Make sure this user exists in configs/users.properties
Run the main() method of this class:
1. You should see that a Chrome browser will open up, and the fixture commands in HelloAppian.java will execute accordingly.
2. Note that this test will fail since your site might not have an action "Create a Case" under menu "Actions" that opens up an interface that has a "Submit" button.

Features

Multiple browser support

Chrome
Firefox

Benefits

Define your own integration tests without being limited by a third-party testing tool
Selenium-based test scripts can be created for reusability throughout test suites
Methods created specifically to operate within Appian applications and Tempo
Test scripts do not need to be updated when upgrading between supported Appian versions
Test scripts are easily updated for new UI changes to a form or interface
Appian design knowledge is not required to create test scripts

Release Notes

March 2025 - Release 25.1

Enhancements
- Added support for defining and using custom locales. Use create appian locale | PATH TO File. This method must be called after setting the version.
  - File must be JSON file with the format: { "dateFormats": [ { "label": "dateFormat", "value": <FORMAT_STRING> }, { "label": "dateDisplayFormat", "value": <FORMAT_STRING> }, { "label": "timeFormat", "value": <FORMAT_STRING> }, { "label": "timeDisplayFormat", "value": <FORMAT_STRING> }, { "label": "datetimeFormat", "value": <FORMAT_STRING> }, { "label": "datetimeDisplayFormat","value": <FORMAT_STRING> } ], "labels": [ { "label": "acceptButton", "value": "Accept" } ], "locale": <LOCALE_CODE> }

August 2024 - Release 24.3

Enhancements
- Added built-in retry to click operation in case of element not interactable exception.
- Updated the milestone locator.

June 2024 - Release 24.2

Enhancements
- Updated locator for site menu links
- Created method which supports clicking on text within an interface. This is particularly useful for nested cards such as tab layouts, but can also be used as a fallback when existing methods don't work. This method is available for all Appian versions.
- Click operation on Card layout will be performed on the left side of the element instead of the right. We're not expecting any impact on existing test cases.

March 2024 - Release 24.1

Enhancements
- Support for Appian version 24.1
- Adds support for collapsing/opening sidebars
- ClickOnCard updated to support clicking on cards with complex content. For example, the method can now click on cards that have a component nested in multiple layouts within the card

November 2023 - Release 23.4

NOTE: Project has been updated to require Java 11 JRE
Enhancements
- Support for Appian version 23.4
- Add support for the side navigation menu in sites
- Add support for downloading charts
- Add support for buttons configured with custom colors
Bug Fixes
- Honor the download directory given in custom.properties for Remote Drivers
- Update dropdowns for versions greater than 23.3 to ignore the aria-checked value
- Fixed Populate Record Type Data Range User Filter method

August 2023 - Release 23.3

NOTE: Project has been updated to require Java 11 JRE
Enhancements
- Supports Appian version 23.3
- Added functionality to interact with new site group headers
- Updated to Selenium 4.11.0
Bug Fixes
- Update checkboxes to support CARD style for 23.3 and later Appian versions

June 2023 - Release 23.2.1

NOTE: Updates to site navigation in the 23.2 product breaks the use of the clickOnMenu method defined in TempoFixtures for site environments. clickOnMenu, and other navigation methods defined in TempoFixtures, are guaranteed to work only in Tempo environments. Use the clickOnSitePage method defined in SitesFixtures instead
Bug Fixes
- Update pickers to recognize selections with links (e.g. Record Pickers)

June 2023 - Release 23.2

Enhancements
- Supports Appian version 23.2
  - NOTE: Updates to site navigation in the 23.2 product breaks the use of the clickOnMenu method defined in TempoFixtures for site environments. clickOnMenu, and other navigation methods defined in TempoFixtures, are guaranteed to work only in Tempo environments. Use the clickOnSitePage method defined in SitesFixtures instead

May 2023 - Release 23.1.2

Bug Fixes
- Fixes an issue where Dropdowns with Search were not working
- Fixes an Issue where verifyText did not work on multi-node components

February 2023 - Release 23.1

Enhancements
- Supports Appian version 23.1
- Updated locator for Dropdown class
Bug Fixes
- Update CVEs
- Update scripts (start.bat, start-mac.sh, start-unix.sh, runFitNesseTest.sh) to reference the new fitnesse-20221219-standalone.jar

August 2022 - Release 22.3

Appian Selenium API is released and supported
Removed support for 20.3

November 2021 - Release 21.4

Enhancements
- Support new card choice components
Bug Fixes
- Update CVEs

August 2021 - Release 21.3

Bug Fixes
- Fix bug for radio button card
- Fix bug for date picker

June 2021 - Release 21.2

Enhancements
- Support new SectionLayout
- Upgrade Selenium Server to 3.141.59
Bug Fixes
- Fix bug for radio button card
- Fix bug for icon link alt text

March 2021 - Release 21.1

Appian Selenium API is released and supported

Tags: testing, Architecture