https://community.appian.com/success/Success center groupen-USTelligent Community 12https://community.appian.com/success/w/tutorial/3472/extending-appianThu, 11 Jun 2026 21:53:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:0bdca772-c829-4f66-a1f2-dc92e62f3fb2joel.larinHow do You Create a Connected System with Integration Objects? How do you call an integration in Appian? In this video, learn how you should use outbound integrations and inbound web APIs to connect Appian with external systems. www.youtube.com/watch Video highlights Integrations are used for connecting and transfering data between Appian and an external system. Outbound integrations are for when Appian initiates the call to an external system, and are build by creating a connected system object and an integration object. Inbound Web APIs are for when an external system needs to call Appian, and are built by creating a Web API object. How to Create a GET Web API Learn how to create a GET web API for an Appian application using the hello, world template. youtu.be/qymPQcPEcQo Video highlights GET Web APIs can be created from a template or from scratch. When using a template, the http method will already be set and the a!httpResponse function, which is used to determine what happens when the API is called, will already be pre-populated. Passing values into the Web API is done through query parameters, headers, in the body of the request, or a combination of these. Web APIs work when an external system sends a request to the endpoint we created in the Web API object. How to Create a POST Web API Learn how to create a POST web API for an Appian application. This POST web API uses a write to datastore entity smart service that allows external systems to write new customer data. youtu.be/kqQPoV8j3_Q Video highlights POST Web APIs allow external systems to create new data in Appian. The Write to Data Store template will convert the data in the body of the request to an Appian value, and then utilize the a!writeToDataStoreEntity smart service to write to a table within Appian. The template also provides functionality for on success and on error. To add test data, create a json blob inside the body with both the field name and the value inside of quotation marks. How to Authenticate Web API Learn how to authenticate a Web API in Appian. Here are three ways that Appian web APIs can authenticate external systems: basic authentication, API key authentication, and OAuth 2.0 Client Credentials Grants. youtu.be/t1g5hKXZ6gA Video highlights Appian APIs can only be called by an external system that has been authenticated, either through an authenticated Appian user or a service account. For basic authentication, a user name that has permission to call the Web API and a password must be provided in the request. API Keys provide a more secure, performant, and long-lasting way to authenticate, using service accounts that have access to the Web API. Oauth 2.0 Client Credentials Grant is an industry standard protocol for authentication, which also uses service accounts to gain access.integrationsapplication designArchitecturehttps://community.appian.com/success/w/guide/3313/automated-testing-with-fitnesse-for-appianThu, 11 Jun 2026 21:52:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:c8850879-8dd5-475d-984d-48e7e52228fajoel.larinPlease 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 For PC, main commands will be: dir: used to show contents of current directory (folder) 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. For Mac/Linux, ls: used to show contents of a directory (folder) 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: automated.testing.home to be TESTING_HOME (e.g. C:\FitNesseForAppian) download.directory to be a folder of your choosing chrome.driver.home to be TESTING_HOME/lib/drivers/chromedriver(.exe if using windows, -mac if using a mac, -linux if using UNIX) 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": }, { "label": "dateDisplayFormat", "value": }, { "label": "timeFormat", "value": }, { "label": "timeDisplayFormat", "value": }, { "label": "datetimeFormat", "value": }, { "label": "datetimeDisplayFormat","value": } ], "labels": [ { "label": "acceptButton", "value": "Accept" } ], "locale": } 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 hiddentestingArchitecturehttps://community.appian.com/success/w/guide/3325/leverage-jmeter-in-appian-load-testingThu, 11 Jun 2026 21:52:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:650c85e5-2fdf-47f2-9168-a7d381b7feb7joel.larinApache 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 = . 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 The upload will succeed and the form will be submitted 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 Open a command window and switch to the /bin directory Rename proxyserver.jks to proxyserver.jks.bak 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. 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) Answer the remaining questions to generate a self-signed certificate in proxyserver.jks Install the certificate on the JMeter proxy server The previous command automatically generates the certificate in the default location Start the JMeter proxy server Access the test site in a browser that uses the JMeter proxy Confirm that the browser shows a warning with the new certificate details Install the certificate on the mobile device Run the following command: keytool -exportcert -keystore proxyserver.jks -alias selfsigned > proxyserver.crt Email proxyserver.crt to your iOS device (or transfer it via another method) Open proxyserver.crt and install it as a trusted root profile on the device 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.testingArchitecturehttps://community.appian.com/success/w/guide/3407/integrating-with-amazon-machine-learningThu, 11 Jun 2026 21:52:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:24adb9fb-f09b-49ea-bf49-fa025c853030joel.larinNote: 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. 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:// /suite/sites/aml and follow the sites wizard to create a new model. On the first tab you can select the S3 bucket created earlier. 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 GuideintegrationsArchitecturehttps://community.appian.com/success/w/guide/3409/fundamentals-of-testing-in-appianThu, 11 Jun 2026 21:52:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:7e5fd8d4-d42b-4897-906e-78449b0086d1joel.larinTesting 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.pdftestingArchitecturehttps://community.appian.com/success/w/guide/3310/automated-testingThu, 11 Jun 2026 21:51:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:5afa3ef4-f658-45cf-82fe-0c7638bd64b4joel.larinAutomated 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 PlayDeliverytestingArchitecturehttps://community.appian.com/success/w/guide/3253/integrating-with-docusignThu, 11 Jun 2026 21:51:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:3e5e8ebb-fe08-477d-b6b4-cb152a852392joel.larinKey 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). Name : Required field, select a unique easy-to-use name. Key : Appian will auto generate it from the name. Description : Optional field, enter an appropriate description. Plug-ins List : Optional field, type “ JWT ” (should show up to select). Credentials : Optional field, add two fields with the following details. 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. Enter appianPrivateKeyPassword as Field Name and leave the value empty. Test Connection: Optional, leave it blank and click “ Save ”. Generate Admin’s Access Token. Create an expression rule to generate the “Access Token.” 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. Use function - createdocusignrsajwttoken() provided by the JWT Plug-in. Note that the plug-in requires you to follow the order of the parameters. Use guidance from DocuSign to generate the JWT . Create an integration to generate the admin access token. Add a rule input for passing the JWT generated in Step 3a(i) 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" For additional guidance, follow the DocuSign documentation Parse the access token from the response. Generate Sender’s Access Token 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) 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). 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. Query Parameters : Add “email” which will be the user’s email address. Headers : Add “Authorization” where the value will be (in expression mode) “Bearer” + the admin’s access token. Parse the “userId” from the generated response and use it in the rule created in Step 3(a) to retrieve the sender’s JWT. Use the integration created in Step 3(b) to generate the sender’s access token. The rule input value will be the sender’s generated JWT. Parse the access token from the response. Create integration to send envelope as the user via DocuSign 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. 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 ConnectintegrationsArchitecturehttps://community.appian.com/success/w/guide/3274/ldap-synchronizationThu, 11 Jun 2026 21:51:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:68b62263-6536-4392-ab1a-b3603da8e75cjoel.larinOverview 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 run Note: 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.integrationsArchitecturehttps://community.appian.com/success/w/guide/3212/fitnesse-for-appian-best-practicesThu, 11 Jun 2026 21:50:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:104db12a-b70a-43c6-9fc2-4f327fbcadaejoel.larinIntroduction 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 “!- -!”. 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:testingArchitecturehttps://community.appian.com/success/w/guide/3100/how-to-estimate-your-appian-projectsThu, 11 Jun 2026 21:50:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:0c6309fb-ee18-4a9c-a5ab-f0d547679c4bjoel.larinSkills 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. Project 001 - Project Description for ROM Estimate.docx community.appian.com/.../Repeatable-Template-_2D00_-Use-Case-Scoping-and-Estimation.docx Indicative Examples - Factors and Estimates.xlsxDeliveryprogram managementProject Estimationhttps://community.appian.com/success/w/article/3402/analyzing-performance-issuesThu, 11 Jun 2026 21:49:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:fdf78302-5ea7-4840-b652-8848d1526720joel.larinWhile using the system, users may encounter slowness and performance issues. The root causes of these issues vary based on usage patterns, application design, system resources, and external factors. For the purposes of this guide, “slowness” is defined as an aspect of the application or platform not responding within an expected, defined range. For example: As an end user, page loads take longer than pre-defined SLAs or seems slow As a designer, Health Check or logs indicate a response time above the defined threshold This guide is designed to help teams methodically investigate reported issues and identify root cause(s) by performing the following steps: Document Issues Triage Issues Analyze Issues Document Issues Your team needs detailed information about the performance issues in order to start the analysis process. A simple email stating that “the system is slow” is not actionable. In order to collect this information, your team must first provide guidance to end users on how to document performance issues. You may also need to train your support staff on how to collect this information. This ensures that the responding team has a sufficient level of information to quickly triage and analyze an issue. The following list provides the minimum data points that should be collected by your support team or by the end users themselves when they experience a performance issue: Name of the user reporting the issue Username of user experiencing the issue URL of the Appian environment Date and time of issue User's environment (e.g. browser type and version, use of VPN/virtual desktop) Steps to reproduce the observed behavior, noting specific screens and/or record/reference IDs related to latency If the issue is experienced in a browser, recording of the network logs captured using the browser’s Developer Tools could be useful. See “How to generate a browser network capture (HAR) file” for more information Encourage the person documenting the issue to be as detailed as possible: What is slow? How slow? What data did you enter? Sample Issue Report Reporter John Smith Username john.smith Site URL https://myapplication.domain.com/suite/sites/mysite Time of issue Between 10:00am and 10:30am EST Environment Windows 10, IE Edge - over VPN Issue Summary / Reproduction Steps I logged in as john.smith and executed the Create Record action from the Finance site. I filled out the "Enter Basic Information" screen with my name and address, and added 10 locations. I clicked Submit, and the system took approximately 30 seconds before displaying the second form ("Enter Additional Details"). I expected the second form to appear within 5 seconds. Type: Value: Triage Issues Performance issues can occur anywhere in an application so the first thing to do is to triage and categorize the reported issues. Looking at the environment metrics in My Appian is a great place to start to determine if performance could be impacting the wider the platform. First, confirm the validity of the usage patterns triggering the reported issue(s). Invalid usage might best be resolved through training or application guardrails rather than in-depth performance analysis and tuning. Some example questions to help you decide this are: Do users have realistic expectations? Is the user seeing SLA violations for response times? Is the reported issue tied to an area of the application that is expected to run longer, such as a large report? Are users utilizing the system as intended? Can users do something they shouldn’t be able to do? Exporting millions of records, or processing extremely large file upload might not be expected or valid. If performance testing, is the test realistic? Poorly designed tests (i.e. higher than expected volume) may result in performance issues. See the Performance Testing Methodology for guidance on test creation and validation. Analyze Issues Initial Analysis Once you've confirmed your application is not performing as expected, your first goal should be to isolate the problem to a specific area of your platform. Start by following the tree below. Once you have reached an endpoint, navigate to the appropriate section below for more information. Restart the decision tree as analysis dictates. Detailed Analysis Network/VPN If all web interactions are slow, including those not associated with Appian, then your issue is likely related to your network connection or specific computer rather than the platform. Check these things first to confirm: Key Questions Potential Issues Next Steps Relevant Logs And Tools Are you on VPN/Citrix, etc.? Latency is sometimes introduced by intermediate web proxies like VPN or Citrix Diagnose Check with peers to see if there is latency on direct network access Action Engage IT/Network support team Network logs Are your peers experiencing similar latency? Issues may be isolated to your machine or region Diagnose Verify if issues are specific to your location (i.e. floor, office, network connection) Action Try different connection Engage IT/Network support team Network logs Web Layer If your web layer interactions are slow: Key Questions Potential Issues Next Steps Relevant Logs And Tools Are nodes load balancing as expected? Load is imbalanced or otherwise not functioning correctly Review load balancing mechanism (mod_jk, F5 device, etc.). Verify network traffic is being routed properly Web server error logs Load balancer logs/configuration Is the Web Server performing as expected? Threads may be stuck, or CPU utilization may be too high for resources available Isolate which threads/requests are causing issues Web server access logs Web server error logs Is granular debugging enabled? Some debugging levels introduce unexpected latency into Web requests Disable any extraneous debugging Web server access logs Web server error logs Web-to-App server connector logs (ISAPI, mod_jk/mod_proxy) App Server Key Questions Potential Issues Next Steps Relevant Logs And Tools Is there high CPU utilization/load average? Application server resources are overloaded Diagnose Look into logs for high volume requests Run thread / heap dumps Review if application follows best practices or is using more resources than expected Action Optimize application to align with best practices Typical Performance Issues Database Performance Consider scaling resources if needed (i.e. add additional CPU) Appian system.csv Is there high heap/garbage collection time? Application components are using a high amount of memory. Typically seen generating documents or working with very large data sets Diagnose Look at logs for risks Action Run thread / heap dumps Consider scaling resources if needed (i.e. add additional memory) Consider adjusting Heap settings Appian system.csv RDBMS If your RDBMS interactions are slow: Key Questions Potential Issues Next Steps Relevant Logs And Tools Are your queries designed efficiently? Queries are under/over indexed Diagnose Run explain plan Analyze Logs Run profiler Review index statistics Action Review the Database Performance play Update indices Redesign queries DB Slow query logs Explain plan Appian data_store*.csv expression*.csv smart_service*.csv perf_monitor_rdbms.csv Are your queries running with the expected parameters? Indexes are not being applied correctly due to unexpected where conditions or casting to unexpected types Diagnose Run explain plan Run profiler Review index statistics Action Update indices Update application DB Explain plan Profiler Appian perf_monitor_rdbms.csv Is the database tuned to support volume and type of queries? Database resources are insufficient; settings, such as buffer/cache are overwhelmed Diagnose Monitor system resources (CPU, Disk Usage, Memory) Action Adjust settings as needed DB System metrics Appian perf_monitor_rdbms.csv Engines Key Questions Potential Issues Next Steps Relevant Logs And Tools Are all engines up? Some engines are not accessible, resulting in some requests failing or bottlenecking on limited resources Diagnose Execute the Check Engine script and confirm all services are available Action Resolve any issues and restart any unavailable services Appian Diagnostics scripts engine status logs engine*.csv perf_monitor*.csv Are your requests load balanced? Some execution services are being under- or over- utilized due to process design patterns Diagnose Execute an All Process reports, and count number of processes per engine Action Review process models for instances of MNI or high number of subprocesses Update to use the Start Process service where possible, or minimize use of MNI Appian Analytics reports Diagnostics scripts engine*.csv top_models*.csv top_process*.csv Are engines overloaded? Engines are overloaded due to high utilization (either throughput or sub-optimal design) Diagnose Review engine performance logs for extremely low Idle time % (<20%) and Work Queue Size increasing Identify expensive processes Action Decrease utilization by optimizing expensive processes Consider scaling engines if needed Appian Analytics reports Diagnostics scripts engine_system.csv perf_monitor*.csv top_models*.csv top_process*.csv Interfaces/Expressions If your interfaces are slow: Key Questions Potential Issues Next Steps Relevant Logs And Tools Do your interfaces rely on external services or complex database queries? The service isn't performant or is not functioning correctly Diagnose Review the interface to look for integration calls (e.g. Integration objects, fn!webservicequery(), a!queryEntity()) Leverage the Performance View and logs to determine if integration calls significantly contribute to overall render time Action If integration based, review the Integrations and RDBMS sections of this guide If not, review the remaining questions in this section Appian Performance view Application server logs expression*.csv data_store*.csv Are your interfaces complicated, or call many expressions? The time to complete numerous tasks causes the overall interface to perform slowly Diagnose Review the Performance View to isolate redundant, high volume or poor performing sections of the interface Action Review the Interface Performance And Debugging and Database Performance plays Improve the design of the identified area Consider simplifying the interface if possible, looking for opportunities to do some of the work on other screens Appian Performance View Application server logs expression*.csv data_store*.csv Integrations If your external integrations are slow: Key Questions Potential Issues Next Steps Relevant Logs And Tools Is there an issue in the service? The service isn't performant or is not functioning correctly Diagnose Isolate performance using debugging tools to replicate transactions outside of Appian Action If test tools show issues as well, engage owner of service If test tools to not show issues, investigate Appian logs further External Tools Fiddler, SoapUI, Postman Appian Application server logs expression*.csv smart_service*.csv integration*.csv HTTP Request/Response Logs Is there any issue with connectivity to the service? The network connection to the service is misconfigured Diagnose Isolate performance using debugging tools to replicate transactions outside of Appian Action Engage IT/Network support team Network logs External Tools Fiddler, SoapUI, Postman Appian Application server logs expression*.csv smart_service*.csv integration*.csv HTTP Request/Response Logs Smart Services If your smart service execution is slow: Key Questions Potential Issues Next Steps Relevant Logs And Tools If a plugin, is the smart service code optimized? Plug-in code might not be optimized for the parameters provided Diagnose Debug code using logging or remote tools to isolate poor performing modules. Ensure the plug-in has been written to follow best practices . Action Update implementation Appian Application server logs expression*.csv smart_service*.csv External Tools Remote or local debugging with IDEschecklistsPerformanceArchitecturehttps://community.appian.com/success/w/article/3299/appian-usage-insights-appian-license-tracking-faqsThu, 11 Jun 2026 21:48:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:90ff1870-237a-4d07-9046-f26831cb625ajoel.larinWhy does my application package include something called “Appian License Tracking”? A recent update to the application led to this name change. The name used to be “Appian Usage Insights” but is now “Appian License Tracking.” The previous name persists on the AppMarket posting for recognition purposes. The application tracks license utilization and may, in future iterations, more closely track application usage based on log availability within Appian. How do I install the apps? The bundled Appian License Tracking Usage Insights Installation Guide describes how to do this. How do I upgrade to the latest version of the apps? The bundled Upgrade Notes document describes how to do this. How should I use the apps? The bundled Appian License Tracking Quick Start Guide describes how to do this. How does the app deduplicate users across environments? Users are identified by distinct username. Their group membership and logins are considered across all environments based on the same username. For example, john.smith in Environment A is considered to be the same user as john.smith in Environment B, but not the same as john.smith@acme.com in Environment C. I’ve run analysis on a collection run but the configuration was wrong. What can I do? You can modify the configuration (business entities, license pools and groups, license types etc) and rerun analysis on the latest collection run as many times as you need to get the configuration right. You can only run analysis on the latest collection run, so once you load the next collection run (a few weeks later) then any further configuration changes will only apply to analysis of that next collection run data. After my latest collection run, why do all license pools have zero allocated licenses? After each new collection run you need to run analysis again on that latest collection run. The majority of the reports are based on the analysis of the latest collection run (except for the capacity planning report and user logins over time), so will not display any data until analysis has been run on the new collection. How do I know which version of the app I am running? From v1.1.0, a constant was introduced in both the Collector and the Reporting apps to display the app version. This has been updated in v2.0.0 to the following based on application name updates. Collector App: LRDC_APPIAN_LICENSE_REPORTING_DATA_COLLECTOR_VERSION Reporting App: ALR_APPIAN_LICENSE_REPORTING_VERSION Information for v1.1.1 and older versions can be found below: For the Reporting app, if the constant LMA_R_APPIAN_USAGE_INSIGHTS_REPORTING_VERSION does not exist in your app, you are either running v1.0.0 or v1.0.1. In this case, if your reporting database includes the Stored Procedure LMA_SP_USERS_BY_LICENCE_TYPE, then you are running v1.0.1. For the Collector app, if the constant LMA_R_APPIAN_USAGE_INSIGHTS_COLLECTOR_VERSION does not exist in your app, then you are running v1.0.1 (which is identical to v1.0.0 as the Collector app did not previously change). How should I configure reporting to see details per app but also grouped at business unit level? From v1.1.0 onwards the Application Quick Start Guide describes how to do this. How do I configure flat app thresholds? From v1.1.0 onwards you can do this via the related action within any license type record. See the Application Quick Start Guide for more information. Do you have examples or scenarios of how to set up the business entities? Business entities are a fairly flexible concept that allow you to model usage in the most appropriate way for your business. A standard approach - that provides an overview at business unit level while allowing visibility on a per-app level too - would be to configure business entities for your organisation's larger business units, and then model the apps that belong to those business units as entity license pools. For this you would create one or more license types per app. For example, you might configure "Finance" as a business unit, create "Fin App1 Enterprise Users", "Fin App2 Enterprise Users" and "Fin App3 Enterprise Users" as license types, and map those to the Finance business entity by creating an entity license pool for each license type within the Finance business entity. For each of those entity license pools, you would configure the groups that allow you to identify users of each of those apps (so the entity license pool for "Fin App1 Enterprise Users" might be the group "Fin App1 All Users", for instance). When you find users that still end up in the Default entity, it's because you haven't mapped a group for them in your Business Entity - license Pool structure. The aim is to end up with no one left in the Default pool, so you know you have configured things correctly. This can take several iterations. Why do I have to upload collection data from all of my environments at once? Usage analysis and the resulting reports are based on a snapshot of usage across all in scope environments at the same time. Therefore, for each new collection run loaded into the reporting application, a collection for every active environment is required. These collections should generally have all been run on the same day, or close enough. From v1.1.0 it is possible to deactivate an environment so that no further collections need to be uploaded for it. This would be used where an environment that was being reported on is no longer being used. Can I use a non-production environment to host the reporting app? You should consider whether your organisation allows the data that the collector application collects to be stored in a non-production environment. Additionally, as you use the application and the data stored in the reporting application grows, you should consider how you manage capacity in your chosen non-production environment. As with any App Market app, clients are responsible for testing these apps in their own environments. When rolling out the Appian License Tracking applications within your organization, ensure that the apps are tested in your non-prod environments first according to your usual testing and release procedures. How can I export the reports? Currently (v1.1.0) the only export functionality included is the high level Usage by Business Entity report, which can be exported via the "Download usage by business entity" download link on the Usage Reports > Usage By Business Entity report. How do you report on non-prod and prod licenses separately, where users need to have one license per environment? Install the reporting app once per environment tier - e.g. a Dev reporting component, one for Test, one for Prod etc. Load only Dev environment collections into the Dev reporting component and so on. How do I configure the collector app to gather login information for the last year? The data collection component will collect a maximum of the last 30 days worth of login information. If you have run the collector in the last 30 days, it will collect the login information since the last time it ran. Over time as the collector is run (at least every 30 days) and the collections are loaded into the reporting component, you will build up login data across a longer period. The application doesn't support collecting older, compressed login audit data. This doesn't prevent the allocation of users to license pools (which is based on the most recent group membership collections). But it does mean that the login information displayed in the app will only become more meaningful as collections are built up over time.monitoringhttps://community.appian.com/success/w/article/3392/machine-learning-overviewThu, 11 Jun 2026 21:48:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:3439a4de-33fa-4d77-939f-3e5561eecd3ajoel.larinAppian is integration agnostic and has the ability to connect with any machine learning offering that exposes itself with a web API. The purpose of this article is to provide information that will empower your general understanding of machine learning technology regardless of the specific tool being used. Refer to the article for Amazon machine learning integrations that have been written about in detail in Appian's documentation. What is Machine Learning? Machine learning is a type of artificial intelligence that uses mathematical models to generate probabilistic predictions by finding patterns in historical data. Machine learning is a subset of AI that focuses on the development of algorithms and models that enable computers to learn and make decisions based on data. The models can be thought of as black boxes that are created by processing many observations both supervised and semi-supervised. These machine learning models are then able to take in one or many observations without a known outcome and produce possible outcomes based on their probabilities. There are many different use cases and applications for machine learning. This article mainly focuses on machine learning technology that analyzes structured data, such as rows of an Excel spreadsheet or an Appian CDT, and delivers a prediction for a specific field or column in the data. The feature, value, or attribute that is being predicted for is often referred to as the target . Within the context of Appian, we’ll dive into the practical implementation of AI features that integrate with applications. Other uses for machine learning include natural language analysis and translation and the ability to decipher image contents, done using tools such as IBM's Watson and Google AI respectively. Appian ML/AI Capabilities Appian AI Skills facilitate the integration of machine learning and AI capabilities into your application. This is done using a variety of low-code design objects, functions and smart services. Features available within Appian AI Skills include document and email classification with custom-built models, and document extraction with pre-trained models. Classification models can be custom-built, including being trained and tested using data that will accurately reflect your use case. The Document Extraction AI skill identifies data from PDF documents, extracting and saving data into key-value pairs that can be used within the application or saved within a database. Appian AI Skills offer pre-trained models that use built-in documentation extraction capabilities. Pre-trained models in Appian are designed for general use cases and are used in documents that have similar information and labeled values (e.g. structured or semi-structured documents). Incorporating Google AI functionalities into your Appian application enables the integration of various features, including but not limited to natural language processing, translation services, cloud-based storage, and mor e . See Using Google AI Services for a full list of features available. Note that starting from January 23, 2024, Appian is no longer selling Appian-provisioned Google credentials to customers. Customers have to purchase the license directly through Google and add their Google credentials to their Appian Admin console . Appian AI Copilot is a starting point to further AI capabilities using Appian. AI Copilot utilizes generative AI to create functional interfaces by generating an initial interface from the fields in your form through a simple pdf upload. AI Copilot is integrated with Azure OpenAI to enable this functionally in your application. Azure OpenAI leverages generative AI models (e.g. gpt-3, codex, dall-e, chatgpt) to provide writing assistance, content generation, etc. You can use AI Copilot to build interfaces directly from a pdf, resulting in a personalized product that can be further customized according to your specific requirements once the initial interface is generated. Machine learning, particularly deep learning, is one of the fundamental components of generative AI. Similarly to other machine learning models, generative AI models undergo training with large amounts of data that aids in identifying inherent patterns. The generative AI model is fine-tuned and enhanced with the introduction of more data over time. Leveraging AI with Appian allows you to automate repetitive tasks and simplify processes, streamlining development and increasing efficiency and productivity. Common Model Types There are two major categories of model types that are used for making machine learning predictions on structured data: Regression : predicts a numeric value. Classification : predicts a categorical value from a discrete, fixed number of possible categories. Classification models can be further broken down into two types: Binary classification : the model has only two prediction values to choose from (ex. true and false). Multiclassification : the model has more than two prediction values to choose from. Which type you utilize is dependent on the target attribute you want to predict for and your overall objective in creating the model. Read the sections below to learn more about the purpose of each model type and see examples describing appropriate uses of each one. Regression Regression models make predictions along a continuous range of numerical values. They have many important use cases (examples below), but can't be used in cases where binary, categorical, or non-numeric values are required without additional processing to the model’s output. The main metric used to determine accuracy of a regression model is the root mean square error (RMSE). The RMSE represents the standard deviation between predicted and actual values; thus a good RMSE is relative to the range of values you are trying to predict. A perfect model would have a RMSE of 0. When using a regression model, be aware that the predicted value may not fall within the range of values provided in training data and might take on any positive or negative number. It is important to have a plan for how to address any values that would fall outside of acceptable ranges for your application. Regression models can be used to predict: The sale price of a home, given information about the home's size, number of bedrooms, zip code, etc. The appropriate salary for a job posting, given information about that job's difficulty and expected characteristics of qualified candidates. The number of viewers who will watch the premiere of a new TV series, given information about the show's genre and cast. Binary Classification Binary classification models predict for a value that has only two possible outcomes. A binary classification model will return a value (true or false) and a predicted score (a number between 0 to 1). By default if a predicted score is greater than 0.5, then the predicted value will be true. However, machine learning tools typically allow you to adjust the score threshold to alter the number of true and false values depending on your use case. The main metric used to evaluate performance of a binary classification model is Area Under the Curve (AUC) . The AUC is represented as a number between 0 and 1. A number closer 1 indicates a highly accurate model. Values near 0.5 represent the model is no better than guessing at random. Values close to 0 indicate the model has learned correct patterns, but is using them to make inverse predictions. Binary classification models can be used to predict: Whether a job candidate should be given an offer of employment, given information about their qualifications and interview scores. Whether a loan application should be approved or rejected, given credit details about the applicant. Whether someone will sign up for a service, given their demographics. Whether a bank transaction is fraudulent, given information about how much that transaction deviates from the account's typical usage patterns. Multiclassification Multiclass models predict for a categorical value from a list of three or more discrete, finite possibilities. A multiclass model will return a list of values and their related probabilities. The value with the highest probability represents the model's best prediction. For example, if you are trying to predict which tier of support a customer service case should be routed to, a multiclass model might return: Tier 1 - 60%, Tier 2 - 13%, Tier 3 - 27%. Since the target attribute's possible values are derived from training data, the model will never deliver a prediction value that did not occur in the training data. The main metric used to determine the accuracy of a multiclass model is called an F1 score . The F1 score is the harmonic mean between precision and recall. The range is 0 to 1. The closer the value is to 1, the better the model. Some machine learning tools set a limit on the number of possible predictable values that a multiclass model can have. This is because target attributes with hundreds or thousands of potential values can be difficult to train and have a higher likelihood of failure and poor model performance. To make predictions from a group of possibilities that is larger than a machine learning tool's limit, consider using a series of different models. For example, to classify animal species from an image, better results can be achieved by first training the model for a more general classification (e.g. feline, canine, rodent). Additional models can be trained to identify specific species. Multiclass classification models can be used to predict: Which category of car—sedan, truck or SUV—someone is likely to purchase, given their demographics. A book's genre, given information about the book's author, length, characters, storyline, etc. Appian AI Skills Use Case: Email Classification The client receives thousands of emails everyday for customer support. Employees manually forward these emails to appropriate departments and locations based on a review of the email description and the customer's location. This process is time consuming and prone to human error. The client can automate this process using the Email Classification AI Skill that combines machine learning and automation. For the new model to be effective, the client must upload a "training set" consisting of a diverse set of emails which includes multiple examples for all desired email routing options.Once the model is trained and tested, the client can publish the model to make it available for use through the Classify Emails smart service . Model Types Summary Model Prediction Type Common Performance Metrics Example Regression Predicts a numeric value Root Mean Square Error (RMSE) Mean Absolute Error (MSE) Predicting a home's sale price Binary Classification Predicts binary values (ex. true or false) Area Under the Curve (AUC) Predicting whether a job candidate should be offered employment Multiclass Classification Predicts values that belong to a limited, predefined set of permissible values F1 Score Log Loss Predicting a book's genre Training Data To create a model, you must supply the machine learning tool with training data that it will use to learn about associations between different attribute values of input data and the target attribute. The model ultimately applies the associations and patterns it found in the training data to make predictions for novel input data. There is a common adage that a model is “only as good as its training data''. If the training data is not a representative sample of the data against which it will be making predictions, the model’s performance will suffer. Below is an example of a data structure that might be used for training data for a model designed to predict the sale price of a used car. In this use case, the column marked "Sale Price" would be identified to the model as the target attribute to predict for. Year Make Model Color Transmission Mileage Previous Owners Sale Price 1997 Ford Mustang Silver Automatic 201,298 3 1,499 2013 Mazda 3 Black Automatic 60,588 1 8,100 2005 Honda Element Red Automatic 160,378 2 4,760 2009 Toyota Camry Blue Manual 87,380 1 7,290 The details about how data should be ordered, formatted and uploaded to a machine learning tool for training vary depending on the specific tool being used, so refer to your tool's documentation for specific information about appropriately presenting data. Best Practices and Tips for Training Data The more training observations (ie. rows of data) that you provide during training, the more accurate the final model will be. This is applicable when a diverse and balanced (e.g. data between class A and B are split equally) set of training data is provided to avoid bias when making predictions. Google has documentation and a video regarding bias and machine learning that is helpful for learning more about this topic. To the greatest extent possible, provide training data that resembles the data you expect to see in production. Machine learning tools typically have both minimal requirements and limits regarding the size and complexity of training data. Read your tool's documentation for more details. Some tools allow you modify the weight given to specific columns during training, or specify a "time" column if training data values are influenced by time. Read your tool's documentation for more details. See Also Websites: Best Practices for Creating Training Data Videos: What is Machine Learning? (2 mins) What is Artificial Intelligence? (5 mins)Machine LearningArchitecturehttps://community.appian.com/success/w/article/3298/performance-testing-initiation-best-practices-checklistThu, 11 Jun 2026 21:46:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:43f50ffd-2e8f-42b1-9e12-be9644edf264joel.larinThese Performance Testing Initiation Best Practices allow teams to identify if they have correctly designed their performance tests before test execution Stakeholder Alignment Item Importance Status Business Stakeholders Identified High IT Stakeholders Identified High Performance Test Architect Identified High Performance Test Engineer Identified Medium Dedicated Performance Test Environment Identified High Non-Functional Requirements Item Importance Status Average Transactions per day for each key flow High Average Transactions per user for each key flow High Peak Transactions during peak hour/minute for each key flow High Data Generated in each table identified for 18+ months past go live High Determine the need for a Performance Test, Load Test, Stress Test or Endurance Test based on the above requirements. High Acceptance Criteria Item Importance Status Targets for 90 percentile Response Time Identified High Targets for transaction throughput identified for each respective test (Performance, Load, Stress and Endurance) based on estimated volumes. High Test Design Item Importance Status Test design incorporates realistic usage scenarios including “think time”. High Test design incorporates variability and realistic test data High ​ ​checklistsPerformanceArchitecturehttps://community.appian.com/success/w/article/3268/deleting-data-in-appian-applicationsThu, 11 Jun 2026 21:45:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:34fc9cac-56be-48d9-9333-f5e366e12bb7joel.larinIntroduction Are you having trouble finding data to debug an issue? Are your queries to a transaction table slow? Did you get a requirement to display activity history for a user? Your Appian application’s data model design and data deletion strategy can have a major role in how these questions or concerns can be addressed. When designing the data model for your Appian application, there are different approaches to consider for data deletion use cases. The approach you choose will probably depend on the nature of the data, the number of transactions, and the business rules associated with the use case. The most common approaches include: hard deletes - actually deleting rows from the table. soft deletes - marking rows as deleted using a flag column e.g. isDeleted or isActive. audit log - creating a separate audit table for recording the nature of transactions taking place on the original table. This article describes the pros and cons of each deletion approach and provides recommendations on when to use these approaches. For the purposes of this article, the relational database data model from the Quote to Order case study is referenced for examples. Figure 1: Quote to Order ERD Hard Deletes The term ”hard delete” is generally accepted to describe the irrevocable removal of data. When a value or row is hard-deleted from a table, it means a DELETE operation has been executed on a row in the table. This is typically the easiest and fastest option for developers, independent of business rules. NOTE : It is recommended to use the Delete from Data Store Entities smart service for hard deleting data from Appian applications. Make sure the deletes are based on an indexed field (ideally the primary key field). You may run the EXPLAIN statement to see the execution plan prior to the delete. If you are deleting in bulk and there’s HA setup at the database layer, it’s preferred to purge in batches (limit to 1000 rows per batch) and during off hours to minimize the impact (database locking) on the application . Be aware of the foreign key constraints and cascade attribute settings in the database schema and make sure your data is backed up prior to the delete in case you need to restore it. Pros Transaction times are faster. Lets you design simple unique and check constraints on table columns. Better data integrity and cardinality of columns in tables. Design allows for creating foreign keys with cascading delete. Cons Risk of data loss due to defects in the application. Lack of traceability of data for business reporting or technical debugging. When to Use A hard delete strategy is better suited for transactional tables with possibly high transaction volume and which do not need historical data for business or technical purposes. In reference to the Quote to Order tables, an example of a hard delete would be deleting a draft order from the QTOT_ORDER table when a user cancels/deletes a draft order. Soft Deletes By contrast to a hard delete, data is typically retained according to a soft delete strategy. Instead of deleting the data, the table row to be soft deleted is marked with a value in a dedicated column.. This option seems less risky in terms of losing data due to hard deletes but could be risky in terms of unintended data showing up in reports or other parts of the application or compromising the performance of the table. Pros Safer approach in general from a perspective of making sure data is not lost. Easy to undo delete operations or reactivate the row if needed. Entire history of the table can be traced in a single table. Cons Tables can grow rapidly and can lead to unnecessary disk usage and bad performance. Complicates maintenance of data integrity due to the need of complex unique indexes and check constraints. Risk of defects being introduced due to designers missing to code the isActive flag into read/write database operations from the application e.g. database view cdts/tables missing the isActive flag field, CDT value used in the write to database smart service missing a value for the isActive flag, etc. Design to support ad-hoc reporting is demanding, in terms of development, with the need to have database views to filter data. Significantly complex views would require materialized views . Low cardinality of the isActive flag column might impact performance of data retrieval despite indexing on the table, especially when 99.99% of the rows have inactive status. When to Use Consider a soft delete approach for operational or reference data as opposed to transactional data or relational mapping tables. For reference data tables instead of creating just an isActive flag to indicate a deleted entry, a START_DATE and END_DATE pair of columns provides a more granular control over retrieval of the data and thus the possibility of viewing the historical usage of your data. See QTOT_REFERENCE table in the ERD above. Audit Log A less invasive approach to deleting data in a table involves creating an audit log of delete operations on the table. It is very common for application designers to have an auditing strategy to record changes done by users in the application. So the audit log approach for recording deletes that happen on a table, as a result of a user’s action or as a business rule, fits right into that strategy. Detailed guidance on implementing audit tables for Appian applications can be found in the Auditing Guidance docs and the Field Level Auditing play. Pros Better data reporting capability for original data and historical reporting of audit data. Separate table for audit allows the original table to perform better due to less accumulation of unnecessary data. Troubleshooting data issues becomes easier given the data in audit tables. Audit tables can have more detail than just a isActive/isDeleted flag e.g. old value, new value, last updated on, update operation - create, update, delete, etc. See QTOT_ACCOUNT_AUDIT table in the ERD above. Cons Longer development time. When to Use For transactional tables e.g. QTOT_ACCOUNT or QTOT_ORDER use the hard delete approach in conjunction with an audit table implementation. Applications typically have event tables to track business events in general. The audit for delete operations can be stored in such event tables. In such implementations, designers would have to transform the data from the original table structure to the event table structure or some other structure of the audit table. Using a JSON structure for the audit data eliminates the need to transform it and makes the implementation easier. Hybrid Approach The Quote to Order data model includes the table QTOA_HISTORICAL_ORDER as part of a data archival strategy. This type of strategy helps with overall application performance. “Mirror” tables that match the structure of the original transaction tables are core to this approach. With these tables in place, a design can be employed in which the application switches between them to access appropriate data depending on its age. For example, in the Quote to Order data model the QTOT_ORDER table has a corresponding QTOA_HISTORICAL_ORDER table. Data from the QTOT_ORDER table is archived to the QTOA_HISTORICAL_ORDER table if it is older than six months and eventually to long term storage after it ages out further. This keeps the size of the QTOT_ORDER table reasonably low leading to better performance. Conclusion A data deletion strategy should be based on the nature of the data and the business case. In summary, use a hybrid implementation approach wherein: Hard deletes are performed on transaction tables in conjunction with audit tables tracking the delete operations. The transaction tables are archived periodically based on the age of the data. Soft deletes are performed on operational or reference tables by marking the data with columns such as START_DATE and END_DATE.databaseArchitecturehttps://community.appian.com/success/p/visionFri, 30 Jan 2026 21:12:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:58edcf04-6193-4e33-8d38-e2d72803bf1bHome Pillar Vision People Delivery Architecture Platform Browse by Category Articles Guides Playbooks Stories Tutorials Success Services Appian Accelerate Expert Delivery Appian Success Plans Appian Academy Shape Your Vision Identify the highest value automation opportunities for your business and connect them to measurable strategic outcomes. Tailored for Appian Leaders Leader Stakeholders Managers Business Leaders Who are Appian Leaders? You need a high-level understanding of the Appian platform to better help position your organization for success. Planner Business Analysts Project Managers Product Owners Who are Appian Planners? You want start or plan an Appian project. You need to know how applications come together, but won’t be building the app yourself. Feature Articles Strategic insights for leveraging Appian in your business. Article Why Process Automation is Right for Your Business Invest in adaptable systems that can meet the needs of today and the demands of tomorrow. Article How to Select the Right Appian Delivery Partner Learn how to select the right Appian delivery partner for your organization. Article Problem Solving: Where to Start, When to Scale Leverage scaling and operational efficiency as part of your transformational strategy. Article Innovate with Process Automation See how businesses automate their processes and integrate flexible delivery models using Appian. See all Articles Guides Step-by-step instructions, and best practices for deploying effective solutions. GUIDE Define your Strategy Defining a strategy is the first step before jumping fully into project development. GUIDE Ideation and Initiation This guide teaches you how to align business objectives with the right Appian technology. GUIDE Select the Right Project Learn how to prioritize project opportunities and match them with the best fitting technology solutions. See all Guideshttps://community.appian.com/success/p/peopleFri, 30 Jan 2026 21:10:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:2446719d-7516-46bc-8956-063535828bdbHome Pillar Vision People Delivery Architecture Platform Browse by Category Articles Guides Playbooks Stories Tutorials Success Services Appian Accelerate Expert Delivery Appian Success Plans Appian Academy Assemble Your Team Build small, agile teams that emphasize teamwork and business expertise. Tailored for Appian Leaders Leader Stakeholders Managers Business Leaders Who are Appian Leaders? You need a high-level understanding of the Appian platform to better help position your organization for success. Planner Business Analysts Project Managers Product Owners Who are Appian Planners? You want start or plan an Appian project. You need to know how applications come together, but won’t be building the app yourself. Feature Articles Strategic insights for leveraging Appian in your business. Article Process Automation Team Essentials Learn about the roles and responsibilities that make up an Appian process automation team. Article Appian Planners: Product Owners and Analysts Learn how product owners and analysts function as process automation planners. Article Build Your Appian Development Team Assemble, structure, and foster the growth of your process automation development team. Article Share Knowledge Across Your Organization Best practices to scale knowledge sharing across your organization. See all Articles Guides Step-by-step instructions, and best practices for deploying effective solutions. GUIDE How to Skill and Structure Your Team Learn how to identify Appian development skill sets and structure your development teams. GUIDE Establish a Learning Culture Put together an action plan to promote your learning culture and make educational content more accessible. GUIDE Train Your Appian Team Take control of your projects and feel confident in your team’s ability to manage your Appian applications. See all Guideshttps://community.appian.com/success/w/article/2977/why-process-automation-is-right-for-your-businessFri, 30 Jan 2026 21:09:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:1437a59b-d261-4757-b9ec-1c73c4f4c3b3Devon LeeOrganizations are transforming at a breakneck pace, driven by rapidly evolving consumer behavior and expectations. New, digitally enabled businesses are upending entire industries and the COVID-19 pandemic has only accelerated the trends. According to an executive Global Survey done by McKinsey , more than half of respondents said they were “investing in technology for competitive advantage or refocusing their entire business around digital technologies.” Compare that to the same survey done pre-pandemic in 2017, where only around 10% of respondents held the same view of technology. The problem is most businesses continue to rely on legacy enterprise systems. These systems are often complex and difficult to change. Over time, they often include patched or jerry-rigged measures to address a myriad of issues. With all this change, one thing is clear—you can’t rely on inflexible technologies and business practices. You need adaptable systems that can meet the needs of today and the demands of tomorrow. Is traditional software development up to the task? Organizational success has become increasingly dependent on technology. Even “non-tech” companies now succeed or fail based on the capabilities of their digital infrastructure. However, the typical technology stack is often complex and opaque. It’s hard to use and years worth of ad-hoc changes have made it even harder to revise. This is only made worse by slow and expensive software development practices. In today’s technological climate, the ability to quickly develop and implement new processes is essential. Whether you’re a hotel providing touchless check-in or a retailer fostering a more efficient and personal online shopping experience-—brands that empower customers with technology are being rewarded. This trend has only been accelerated further by the onset of the pandemic, where agility and adaptability have in some cases meant the difference between thriving and just surviving. If you were quick to put in place contactless protocols, you could get back to work faster than those with inflexible systems. Given this increasing need for agile and flexible software development, traditional methods of hand-coding software can’t keep up. The traditional software development model consists of large, centralized teams of specialized developers. These teams work within highly planned and rigid processes and fail to adequately address the complex automation needs of today's digital enterprise. If you're stuck with outmoded or rigid legacy processes, you won't be able to adapt to your users changing needs and may risk losing them. Compounding the problem are a complex set of circumstances, including: Unprecedented new operating environments. The COVID-19 pandemic ushered in a world of continuous disruption and adaptation. It forced organizations to create processes for remote work. It also called for new safety, testing and tracking protocols. Changing regulatory requirements. From environmental protections to accounting standards—new rules and regulations result in costly workflow modifications. Evolving expectations. Customers and employees expect high-quality, streamlined and intuitive user experiences. The bar is now set by their favorite brands at home, rather than those at work. Companies must continually enhance the customer journey by leveraging data and digitizing functions. Global growth opportunities. Global markets enable organizations to sell and source materials in new territories. Technology is not only making new products and services possible, but also changing how you market and deliver them. But, without the time and resources to invest, businesses risk missing out. Navigating all this uncertainty requires more streamlined, automated digital workflows. And this must be done as rapidly and cost-effectively as possible. Low-Code: Flexible, Resilient and Adaptable To thrive in this new reality, enterprise software today must be flexible, resilient and adaptable. You need customizable automation that can change according to dynamic needs. You also need automated workflows that are custom mapped to unique goals and real-world challenges, not just the most common scenarios. Most of all, you need to increase speed and lower the cost of development. Fortunately, low-code development platforms reduce the burden of building enterprise applications. Meaning you can now build apps and streamline workflows faster and cheaper than ever before. Low-code lets you leverage existing technology investments, and extend capabilities. It reduces buildout time and cost, and enables you to effectively automate functions to compete in this new paradigm. An Economic Impact Study conducted by Forrester found that customers using Appian’s low-code platform: Accelerated application creation by 17x Improved time-to-value of applications by 50% Realized a 389% return on investment (ROI) Those outcomes were made possible by two distinct advantages low-code offers to developers: Speed and Ease of Use. Low-code allows developers to work rapidly by selecting from a library of ready-made tools or empowering them to make their own reusable tools. In addition, low-code removes the barrier to entry to software development. Rather than each developer needing a solid command of Java, HTML, CSS, PHP, SQL (not to mention third party API frameworks ), each team member only needs to know Appian, which creates bandwidth for what’s most important: solving real business problems. At its core, low-code does away with much of the time and resource intensive high-code development requirements. Appian pioneered and continues to lead the low-code development space by providing best-of-breed integrated development tools, in addition to a full suite of tools designed to help you unify your data, build apps, and automate your business.Visionhttps://community.appian.com/success/w/article/2979/innovate-with-process-automationFri, 30 Jan 2026 21:07:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:0393af37-6c84-4ffa-a2ed-86f1384e0407Devon LeeTo be competitive today, it’s not enough for businesses to be efficient; they also need to innovate according to their own unique vision. They need to offer dynamic products and services that can respond to the distinct demands and requirements of their users. However, building a new product or service is a time and resource intensive undertaking. This is even more pronounced when developing solutions that don't fit nicely into pre-established product delivery pipelines. Manual tasks, inflexible processes and complicated business rules all get in the way of offering unconventional or game-changing product lines. Innovation, by definition, requires some coloring outside the lines. And this is where low-code can make all the difference, by helping businesses automate their processes and integrate more flexible delivery models. Innovation for differentiation In the sometimes conservative and highly regulated world of finance, innovation can be hard to come by. But institutions with an eye towards digital transformation are increasingly differentiating themselves in a highly competitive market. Let’s take a look at SEB Investor Services, one of the leading providers of asset servicing to institutional investors in the Nordic region, to see how low-code drives innovation. SEB saw an opportunity to offer its clients services outside the traditional securities most banks provide, namely shares, bonds, derivatives, and funds. They wanted to add alternative assets–wind and solar, private equity, venture capital holdings–to their portfolio, so as to better serve the diverse needs of their clients. In the past, SEB offered relatively few alternative assets due to the manual labor and high degree of operational difficulty required to provide the service. They needed to find a way to automate the handling of these assets, without having to bring in a full team of developers to create and maintain the service. That’s when the SEB team identified low-code as the perfect solution to quickly and efficiently move forward with their plan. Using the Appian platform, they were able to reconfigure and automate complex business rules, as well as the unique workflows and data structures associated with alternative assets. In an interview given to PostTrade 360° , SEB Product Manager Frederik Söderlund described the process of using low code to realize the project: The big projects cost big money – with large project groups, consultants and testing. But when you start from a blank sheet today, using new technology based on blocks that you assemble in lego style, with pre-defined integrations and self-testing capabilities…it gets so much easier. Fredrik Söderlund, Product manager for portfolio solutions at SEB Investor Services/LCFI In addition to automating the handling of alternative assets, SEB was also able to employ AI-powered IDP (Intelligent Document Processing ) to help extract and interpret investment data. This holistic approach enabled them to not only increase the number of alternative assets available to their clients, but to maximize value from returns on those investments. By partnering with Appian, SEB was able to take one of finance’s least standardized processes and unlock new, value-added product offerings from it. Disruptive innovation Disruption shouldn’t be a business goal in and of itself. But innovation often has the side effect of disrupting those arenas that are no longer providing an optimal experience. Since the advent of ridesharing companies, the commonly held belief was that congestion and pollution would decrease as more single drivers opted for these services. However, a study conducted by Researchers from the University of Kentucky and the San Francisco County Transportation Authority found that transportation network companies (TNC’S) were actually the largest contributor to increased congestion in cities like San Francisco. Enterprise Holdings, Inc, manager of the largest and most diverse privately-owned fleet of vehicles in the world, identified an opportunity to innovate within the ridesharing industry. The plan was to target a traditionally underserved market of vanpool commuters , namely people traveling to work in groups of more than 3 or 4. The goal was to provide these commuters with a lower-cost, more environmentally friendly commuting option. However, existing systems within the company could not accommodate a new business with a radically different operating model and workflow. Building a custom application using traditional methods would have taken years, causing Enterprise to miss their window of opportunity. Using Appian, Enterprise was able to realize this vision and create Commute , the company’s vanpooling service, in just 4 months. Commute programs are organized by an employer and typically consist of 4 to 15 coworkers traveling together. Commuters coordinate a central meeting location, board a late-model, low-mileage van or SUV from the company’s fleet, and take turns driving to and from work. This gives commuters time to read, relax, catch up on some work, or even stream their favorite shows with WIFI enabled vans. We adopted Appian's platform for Enterprise Rideshare because it combines the best of business process management, social business, mobile access and cloud deployment. The result is a truly modern business management platform that supports our objective of providing commuters with a smarter, better way to get to work. Ryan Johnson, Assistant Vice President of Enterprise Holdings Commute not only helps workers reduce the financial burden of commuting, but also lets them arrive at work less stressed, leading to higher productivity. After partnering with Appian, Commute has scaled to operate more than 11,000 vanpools in 45 states. It removes more than 40,000 vehicles off the road every day and eliminates an estimated 900 million commuter miles annually. To top it all off, the program also reduces more than 695 millions pounds of carbon emissions annually . We’ve seen how low-code can be a driver for innovation, whether in more historically conservative fields such as finance, or in burgeoning industries such as ridesharing. Low-code enables businesses to work more quickly, efficiently, and cost effective. Dynamic business conditions and evolving user demands will always put pressure on businesses to innovate. With low-code integrated into their digital strategy, imaginative organizations can respond quickly and decisively, while continuing to push the envelope on their personal strategic vision.Visionhttps://community.appian.com/success/w/article/2987/process-automation-team-essentialsFri, 30 Jan 2026 21:06:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:acd3fd56-dca9-4c3f-ac33-85d74ec0a6f2Devon LeeOne of the most common questions we receive focuses on how to structure an organization for low-code success. There isn’t a one-size-fits-all answer to this question, but we do have a few guidelines for getting started. The most important part is thinking of your Appian-trained workforce as a team, with mutually supportive roles and responsibilities across the organization. At Appian, we think a successful team is a combination of a few select roles that each play an important role in a project’s success: Leaders Planners Builders Administrators Let’s dig a little bit deeper into each of these team roles, why they are important, and what they need to know. Appian Leaders For our purposes, leaders include business stakeholders, managers, or executives who need awareness of low-code automation capabilities but aren't heavily involved in the development process. They are, however, stakeholders and decision makers responsible for an organization’s success. They often control the budget, people, and determine the desired outcomes of projects. To be successful, these leaders need to understand the capabilities of Appian and how it can solve their problems. Leaders also need to understand how to source, train, and structure their teams for ongoing success, and they’ll usually want to know what pitfalls to look out for when automating portions of their business. See our Vision pillar for resources geared towards Appian Leaders. Appian Planners The planner role defines the processes to be automated, prioritizes development efforts, and ensures coordination with other business units. The most common job titles we see functioning in the planner role include business analysts, product owners, project managers, scrum masters, and UX designers. Some organizations have distinct team members assigned to each role, while others may have a single individual functioning across multiple roles. At a minimum, you should plan to include both a product owner and an analyst as part of your Appian team. This will ensure your organization is positioned for success. Appian planners need a strong understanding of the Appian delivery methodology and a basic understanding of how Appian objects come together to make applications. See our Delivery pillar for more resources geared towards Appian Planners. Appian Builders Builders, or developers , are the core of any Appian delivery team. Their primary job is taking requirements produced by the analysts, prioritizing them with the product owner, and converting them into applications using the Appian process automation platform. Functionally, the role of an Appian builder can be broken down into the following positions: Low-Code Developers Lead Developers Quality Assurance Appian strongly recommends a Team of 3 structure for most projects, with larger projects or initiatives distributed across multiple teams. Each team should be cross-functional in so much as any member of the team can take on any task when needed. Naturally, some team members will be stronger in certain skills than others, but we’ve found that high-performing, multi-disciplinary teams are best suited for success. For example, a low-code developer often falls into the “Developer and…” paradigm. This means that a particular team member might fall into a dual role as a low-code developer, in addition to acting as an architect, scrum master, UX lead, or test manager. When building these small cross-functional teams, it’s important to look for team members that have skills outside of their primary role or function. Whether that’s an interest in data models, integrations, or process mining, looking out for complimentary skills is the best way to establish a versatile low-code team. Administrators Administrators own responsibility for the Appian system and supporting infrastructure. This includes overseeing server admins, database administrators, IT staff, or anyone supporting the application’s backend. Administrators are most often concerned with the security implications of the Appian platform and how it interacts with their internal systems. This includes things such as data management, web APIs, user accounts and more. Although administrators aren’t usually involved in development themselves, they work closely with lead developers to define technical requirements and boundaries. To this end, administrators should pursue a basic level of training to better understand the terminology and underlying infrastructure of the Appian platform. Application Administrators Application Administrators are employees of the customer organization responsible for the maintenance and support of individual applications. They’re typically in charge of user management, performing basic clean-up and housekeeping activities, and serve as the first layer of support to triage tickets and issues. At a high level, Application Administrators understand how Appian objects interact with one another to form an application, but aren’t developers themselves. They perform basic troubleshooting activities, and are knowledgeable on navigating Appian support systems to get resolution on more complicated issues. Application Admins are also familiar with tools including Health Check, Health Dashboard, and MyAppian . To support this role, we developed the Appian Application Administrator course , available through Appian Academy.People