Appian Knowledge Base

KB-1447 Appian Cloud Vulnerability Testing

Kaushal Patel — Tue, 14 Apr 2026 15:29:27 GMT

Current Revision posted to Appian Knowledge Base by Kaushal Patel on 4/14/2026 3:29:27 PM

Purpose

Cloud customers can perform security-related activities against their Appian environments such as penetration testing and vulnerability scanning as well as software composition analysis scans on installers, containers and plugin jars. This article outlines assessment rules and accepted formats for submitting vulnerabilities to Appian.

Appian Cloud Assessment Rules

All planned security testing by customers must be submitted to Appian Technical Support at least 3 US business days (Mon-Fri 9:00 AM to 6:00 PM EST/EDT)
prior to testing via a support case.
The following details must be provided in the support case to prevent Appian or its hosting service providers from adding the test source IP addresses to a block list:
- Contact information
- Start time of test (including timezone)
- Test duration
- Expected peak bandwidth in Gigabits per second (Gbps)
- Source IP addresses generating the test traffic
Only perform assessments against the Appian Cloud Sites or FQDNs for which you have explicit approval.
Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service.
Social engineering (e.g. phishing, vishing, smishing) is prohibited.
Denial of service attacks are prohibited.
Appian recommends performing assessments against a test or development site whenever possible, rather than a production site.
Appian considers any information identified during a security test of an Appian Cloud site to be Confidential Information that is protected under Appian’s contractual agreements with its customers. This obligation to protect Appian’s Confidential Information must flow down to any third-party security consultants hired by Appian customers. Please indicate in the support case whether a third-party entity will be used for security testing and whether the third-party entity has executed a non-disclosure agreement appropriate for the purpose.

Submitting Results

The following applies to all submissions:

Appian reviews security scan results only for recent hotfixes. Customers running older hotfix versions should upgrade to a recent hotfix and resubmit security scan results before Appian team initiates review.
All documentation (including results, summaries, and reproduction steps) must be submitted in English.
Appian will not accept findings that are missing information within the provided templates.
Submissions much be done via support case.

Appian Vulnerabilities

This section is applicable to penetration testing or vulnerability scans against Appian installations.

Fill out the Appian Vulnerability Submission Worksheet according the instructions below:

All submitted vulnerabilities must be validated by the assessor prior to submission. Appian does not accept invalidated results or direct output from automated scanners without additional manual validation.
Appian requires verifiable evidence such as screenshots, payloads, or any other associated proof-of-concept material as well as manual reproduction steps in order to properly validate any reported vulnerability findings.
All scanning or testing documentation must be accompanied by:
- A summarized index of all issues found, with the severity level of each issue.
- Clear evidence performed by the assessor showing that the proposed vulnerability can be used to exploit the system, for example by:
  - Allowing inappropriate access to the system or its data.
  - Allowing inappropriate modification of the system or its data.
  - Inappropriate use of a component of the system or as a whole.
- A description of the risk to the system.
- Guidance on how to reach the impacted end point(s).
- Clear steps on how to reproduce the issue.

Appian Third-Party Component Vulnerabilities

This section is applicable to Software Composition Analysis scans against Appian installers, containers and plugin jars.

Fill out the Appian third-party vulnerability submission worksheet according to the instructions below:

If the vulnerability reporting source is vendor specific (ex: BlackDuck or X-Ray), the customer should provide as much explanatory detail as possible in the Description column in order for Appian to effectively validate the issue.

What to Expect Next

Appian will review the findings (assuming all submission requirements have been met) and either accept or reject each one.
- For rejected findings, Appian will provide an explanation as to why the reported vulnerability was rejected (false positive, configuration-level controls available to mitigate, etc.).
- For accepted findings, Appian will classify the severity of the finding as Low/Medium/High/Critical.
Appian Support will provide analyses and impact assessments of the report and individual findings through the support case.

Affected Versions

This article applies to all versions of Appian Cloud

Last Reviewed: April 2026

Tags: Security, Cloud

KB-1354 How to manage high disk usage in Appian Cloud environments

pauline.delacruz — Fri, 03 Apr 2026 14:31:32 GMT

Current Revision posted to Appian Knowledge Base by pauline.delacruz on 4/3/2026 2:31:32 PM

Purpose

This article details root causes as well as corrective actions to be taken in situations where an Appian Cloud environment is experiencing high disk usage. In addition, some strategies to optimize and control disk usage in Appian environments are listed. In Appian Cloud environments specifically, the top disk consumers are usually those that are listed below.

Note: Appian Support may open a Support Case to notify you if disk usage in your environment crosses 80%. A member of Appian Support will follow up on the Support Case to discuss the largest consumers of disk on your site and potential remediation steps.

Instructions

Depending on which component of Appian is causing high disk usage, the steps to remediate the issue will vary.

Purchasing additional disk usage

It is possible that sufficient cleanup of actionable consumers of disk is not possible. In this situation, a disk space increase may be necessary to bring disk usage to healthy levels.

This is especially common for sites with 75 GB of storage. This amount of storage space is the minimum that can be provisioned for an Appian Cloud environment and is meant to be used only as a starting point for customers. Many Appian Cloud environments will experience a workload whose storage requirements exceed 75 GB of disk space, therefore requiring a disk space increase.

Additional storage is hot-deployable, meaning a site restart is not required to add additional disk space.

Note: Once additional disk space has been added to the server, it cannot be removed.

Knowledge Centers & Documents

Knowledge Centers are one of the most common causes for high disk usage in Appian Cloud environments. You are responsible for deleting any unnecessary documents in the appropriate knowledge centers. Appian Support is unable to delete documents for you on Cloud sites.

Appian Support can provide a breakdown of the largest Knowledge Centers as requested. If you already have a Support Case for addressing high disk usage in your environment, you can request this breakdown in that Support Case. Otherwise, you can create a new Support Case to request this breakdown.

In order to access and delete the documents in the specified knowledge centers, perform the following:

Navigate to <APPIAN_URL>/suite/design/.
Click on the Objects tab.
Filter by the Folder object type.
Type <id> in the search bar, where <id> is one of the IDs in the breakdown provided.
Click Search.
Select "Search UUID and ID" in the dropdown to the right of the search bar.

KC 0 and KC 7

You may see Appian Support reference KC 0 or KC 7 in a disk breakdown. These are unique Knowledge Centers which are present in every Appian environment.

KC 0 contains system images, import/export logs, and deployment packages. This folder cannot be accessed from the frontend. Deployment packages are automatically deleted after 30 days, and you can modify this retention period in the Appian Administration Console. All other files in this folder are stored indefinitely. Appian Support can manually remove files older than a certain number of days from this folder with your permission. To request this manual cleanup, please update your high disk usage Support Case (if one exists) or open a new Support Case.

KC 7 is the Temporary Documents Knowledge Center. By default, files are kept in this Knowledge Center for 30 days. This retention period can be modified by Appian Support. To request a change to this retention period, please update your high disk usage Support Case (if one exists) or open a new Support Case.

Logs

Application logs will naturally accumulate in your environment. Application logs using a high amount of disk is not necessarily a cause for immediate concern. However, if application logs are growing rapidly or if disk space is limited, this may require further attention.

While many application logs roll over or are compressed after a certain number of days, there are no global settings for managing log files. Appian Support can compress application logs older than a certain number of days as necessary. To request cleanup of application logs on your site, please update your high disk usage Support Case (if one exists) or open a new Support Case. Compressed logs will still be available to download via <APPIAN_URL>/suite/logs as a .gz file.

If application logs have grown a significant amount in a short time, this can be indicative of a recurring issue in your Appian environment that is repeatedly printing errors in the logs. These errors should be addressed as soon as possible to avoid further increases in disk space.

If you have requested additional loggers to be enabled or existing loggers to be modified, it is important that you let Appian Support know as soon as these loggers can be disabled. Leaving them on can increase the size and disk utilization of the logs and is not recommended for long periods of time. Note that all loggers will be reset to default values upon a site restart.

RDBMS Data

The amount of disk space that the Appian Cloud Database consumes is directly related to the amount of data being stored in the database.

If MySQL data is using a high amount of disk space, consider reducing the amount of data stored in the cloud database. Alternatively, consider moving the data from the Appian Cloud server to an external database server.

Note: If rows are deleted from the cloud database, disk space may not immediately be freed. This is because the rows are not immediately removed, just marked as "deleted" internally. If you delete data from your cloud database but do not see a drop in disk usage, please reach out to Appian Support via Support Case. Appian Support can review your cloud database and reclaim disk space from deleted rows if necessary.

RDBMS Logs

In addition to the RDBMS data mentioned above, all connections made to your cloud database are audited, and all operations performed on the cloud database are stored in the RDBMS binary logs. By default, the binary logs are purged after four days, and the audit logs are removed after 30 days. However, on compliant sites, the audit logs are kept indefinitely for security purposes.

If either of these types of logs are consuming a significant amount of disk space on your site, consider reducing the amount of activity on your cloud database. Alternatively, feel free to open a Support Case with Appian Support to discuss additional options.

Archived Processes and Process History

Processes which have been archived are moved out of memory and onto disk. Additionally, the process history for all processes is stored on disk. If archived processes or process history are the top consumers of disk space in your environment, there are a few site properties that can be configured by Appian Support to remediate the issue going forward.

Auto-compress archived processes - The site can be configured to automatically compress archived processes after a certain number of days (e.g. automatically compress archives older than 7 days). A compressed archived process can still be unarchived normally.
Auto-delete archived processes - The site can be configured to automatically delete process archives after a number of days (e.g. automatically delete archives older than 7 days). Once an archived process is deleted, it cannot be recovered or unarchived.
Auto-delete process history - The site can be configured to automatically delete process history after a number of days (e.g. automatically delete process history older than 7 days). Once a process has its history deleted, that process can no longer be viewed from the frontend.

Appian Support requires that you provide a number of days to set as the value for the properties above. Additionally, the properties for auto-deletion of archived processes and process history must be configured to the same number of days. Please be aware that Appian Support will need to schedule a maintenance window to deploy any changes to these properties.

Note: Archived processes are automatically compressed after 7 days by default.

Engine Transactions and KDBs

The engines are processes that run in memory, but they frequently write data to disk. The most common culprits of high disk usage related to the engines are engine transactions and KDBs.

Engine Transactions

Engine transactions are copies of every write transaction that gets applied to the engines. They are used to rebuild the engine in case of an unexpected crash.

Appian Support may refer to engine transactions as Kafka logs, since they are managed by Kafka. However, unlike normal log files, engine transactions cannot be manually deleted. Instead, they automatically roll over whenever the engines checkpoint. By default, the engines will try to checkpoint at least every 22 hours, and the latest three checkpoints are saved by default.

If the engine transactions are taking up a high amount of disk space, try reviewing the processes running on your site. Typically, engine transactions scale with the amount of process activity on a site, but certain design implementations (extremely large process variables or many looping processes) can cause extreme growth of the engine transactions. Reach out to Appian Support via Support Case if you have any questions or suspect that engine transactions are responsible for a significant amount of disk usage on your site.

Engine KDBs

Whenever the engines checkpoint, they store a snapshot of themselves on disk. This snapshot is referred to as a KDB file. Just like engine transactions, only the past three KDB files are saved by default, and they roll over with each checkpoint.

If the engine KDBs are taking up a high amount of disk space, this means that the engines themselves must be taking up a lot of RAM. Please review KB-2011 on addressing high engine memory usage and try to lower the memory used by the engines. Reducing the memory footprint of the engines will lead to a drop in the size of the KDB files for that engine after the next checkpoint.

RPA Executions

Robotic executions on your site will generate many artifacts, including screenshots, execution videos, and execution logs. If robotic executions are responsible for a significant amount of disk usage, please review the Automatic Process Clean-Up options for your robotic tasks. Consider modifying the clean-up properties associated with your robotic tasks to help reduce the amount of disk space taken by their respective artifacts.

RPA Logs

RPA logs will naturally accumulate on your site as you use RPA. If you are actively using RPA, please navigate to the RPA Console, select "Settings" on the left-hand sidebar, and select "Maintenance". This will allow you to review, download, and delete RPA logs on your site. You may also reach out to Appian Support to request the compression or deletion of RPA logs.

If you are not using RPA on your site and RPA logs are still taking a noticeable amount of disk space, please reach out to Appian Support.

Affected Versions

This article applies to all versions of Appian.

Last Reviewed: April 2026

Tags: administration, how-to, disk usage, Cloud

KB-1354 How to manage high disk usage in Appian Cloud environments

pauline.delacruz — Fri, 03 Apr 2026 14:30:22 GMT

Revision 15 posted to Appian Knowledge Base by pauline.delacruz on 4/3/2026 2:30:22 PM

Purpose

Instructions

Depending on which component of Appian is causing high disk usage, the steps to remediate the issue will vary.

Purchasing additional disk usage

It is possible that sufficient cleanup of actionable consumers of disk is not possible. In this situation, a disk space increase may be necessary to bring disk usage to healthy levels.

Additional storage is hot-deployable, meaning a site restart is not required to add additional disk space.

Note: Once additional disk space has been added to the server, it cannot be removed.

Actionable Components

Knowledge Centers & Documents

In order to access and delete the documents in the specified knowledge centers, perform the following:

Navigate to <APPIAN_URL>/suite/design/.
Click on the Objects tab.
Filter by the Folder object type.
Type <id> in the search bar, where <id> is one of the IDs in the breakdown provided.
Click Search.
Select "Search UUID and ID" in the dropdown to the right of the search bar.

KC 0 and KC 7

You may see Appian Support reference KC 0 or KC 7 in a disk breakdown. These are unique Knowledge Centers which are present in every Appian environment.

Logs

RDBMS Data

The amount of disk space that the Appian Cloud Database consumes is directly related to the amount of data being stored in the database.

RDBMS Logs

Archived Processes and Process History

Auto-compress archived processes - The site can be configured to automatically compress archived processes after a certain number of days (e.g. automatically compress archives older than 7 days). A compressed archived process can still be unarchived normally.
Auto-delete archived processes - The site can be configured to automatically delete process archives after a number of days (e.g. automatically delete archives older than 7 days). Once an archived process is deleted, it cannot be recovered or unarchived.
Auto-delete process history - The site can be configured to automatically delete process history after a number of days (e.g. automatically delete process history older than 7 days). Once a process has its history deleted, that process can no longer be viewed from the frontend.

Note: Archived processes are automatically compressed after 7 days by default.

Engine Transactions and KDBs

The engines are processes that run in memory, but they frequently write data to disk. The most common culprits of high disk usage related to the engines are engine transactions and KDBs.

Engine Transactions

Engine transactions are copies of every write transaction that gets applied to the engines. They are used to rebuild the engine in case of an unexpected crash.

Engine KDBs

RPA Executions

RPA Logs

If you are not using RPA on your site and RPA logs are still taking a noticeable amount of disk space, please reach out to Appian Support.

Affected Versions

This article applies to all versions of Appian.

Last Reviewed: April 2026

Tags: administration, how-to, disk usage, Cloud

KB-2377 Information about the TeamPCP / CanisterWorm Supply Chain compromise

Kaushal Patel — Thu, 02 Apr 2026 17:24:45 GMT

Current Revision posted to Appian Knowledge Base by Kaushal Patel on 4/2/2026 5:24:45 PM

In late February and March 2026, a widespread supply chain campaign orchestrated by a threat actor known as TeamPCP (associated with the "CanisterWorm" malware) compromised over 50 open-source libraries across multiple ecosystems, including PyPI, npm, Docker Hub, and GitHub Actions.

While the campaign impacted dozens of libraries, notable targets included the litellm library on PyPI (versions 1.82.7 and 1.82.8) and Aqua Security's vulnerability scanner, Trivy (CVE-2026-33634).

Appian has investigated this broader campaign and affected services, and determined that it is not impacted. No vulnerable versions of the affected libraries associated with the TeamPCP/CanisterWorm compromise are present in the Appian Cloud environment or any of Appian’s products. We will continue to monitor the situation and provide any updates as appropriate.

Additional Notes:

The following CVE was released with additional information on the scope of the vulnerability:

CVE-2026-33634 - (Aquasecurity Trivy Embedded Malicious Code Vulnerability)

Supporting Documentation:

Affected Versions

This article applies to all supported versions of Appian.

Last reviewed: April 2, 2026

Tags: Security

KB-2377 Information about the TeamPCP / CanisterWorm Supply Chain compromise

Kaushal Patel — Thu, 02 Apr 2026 17:24:34 GMT

Revision 2 posted to Appian Knowledge Base by Kaushal Patel on 4/2/2026 5:24:34 PM

While the campaign impacted dozens of libraries, notable targets included the litellm library on PyPI (versions 1.82.7 and 1.82.8) and Aqua Security's vulnerability scanner, Trivy (CVE-2026-33634).

Additional Notes:

The following CVE was released with additional information on the scope of the vulnerability:

CVE-2026-33634 - (Aquasecurity Trivy Embedded Malicious Code Vulnerability)

Supporting Documentation:

Affected Versions

This article applies to all supported versions of Appian.

Last reviewed: April 2, 2026

KB-XXXX Information about the TeamPCP / CanisterWorm Supply Chain compromise

Kaushal Patel — Thu, 02 Apr 2026 17:24:18 GMT

Revision 1 posted to Appian Knowledge Base by Kaushal Patel on 4/2/2026 5:24:18 PM

While the campaign impacted dozens of libraries, notable targets included the litellm library on PyPI (versions 1.82.7 and 1.82.8) and Aqua Security's vulnerability scanner, Trivy (CVE-2026-33634).

Additional Notes:

The following CVE was released with additional information on the scope of the vulnerability:

CVE-2026-33634 - (Aquasecurity Trivy Embedded Malicious Code Vulnerability)

Supporting Documentation:

Affected Versions

This article applies to all supported versions of Appian.

Last reviewed: April 2, 2026

KB-2376 Information about the Axios Supply Chain Compromise

Kaushal Patel — Wed, 01 Apr 2026 20:38:57 GMT

Current Revision posted to Appian Knowledge Base by Kaushal Patel on 4/1/2026 8:38:57 PM

On 31 March 2026, an Axios npm package that uses a JavaScript library to enable applications to make HTTP/S requests and is included as a dependency in millions of applications was compromised. Between ~00:21 and ~03:30 UTC, malicious versions (axios@1.14.1 and axios@0.30.4) were published using a compromised maintainer account.

Appian has investigated this vulnerability and affected services, and determined that it is not impacted, as no vulnerable versions of the packages are used in the Appian Cloud environment or any of Appian’s products. We will continue to monitor the situation and provide any updates as appropriate.

Supporting Documentation:

Affected Versions

This article applies to all supported versions of Appian.

Last reviewed: April 1, 2026

Tags: Security

KB-2376 Information about the Axios Supply Chain Compromise

Kaushal Patel — Wed, 01 Apr 2026 20:34:59 GMT

Revision 2 posted to Appian Knowledge Base by Kaushal Patel on 4/1/2026 8:34:59 PM

Supporting Documentation:

Affected Versions

This article applies to all supported versions of Appian.

Last reviewed: April 1, 2026

KB-XXXX Information about the Axios Supply Chain Compromise

Kaushal Patel — Wed, 01 Apr 2026 20:31:01 GMT

Revision 1 posted to Appian Knowledge Base by Kaushal Patel on 4/1/2026 8:31:01 PM

Supporting Documentation:

Affected Versions

This article applies to all supported versions of Appian.

Last reviewed: April 1, 2026

KB-1157 How to reset the analytics engines for self-managed installations of Appian

pauline.delacruz — Wed, 01 Apr 2026 16:43:59 GMT

Current Revision posted to Appian Knowledge Base by pauline.delacruz on 4/1/2026 4:43:59 PM

Purpose

This article outlines the process to reset the Analytics Engines in self-managed installations of Appian.

NOTE: These steps should only be performed when advised to do so by Appian Technical Support. They should only be performed on the process analytics engine. These steps are not supported on any other engine.

Instructions

Note: For the most up-to-date steps, always refer to the official Appian documentation. The steps below are provided as a reference for common deployment types.

Appian on Kubernetes (AoK)

Resetting the analytics engines on AoK requires a number of extra steps.

Shut down the webapp cluster by scaling its statefulset to 0.

kubectl -n <namespace> scale statefulset appian-webapp --replicas=0

Checkpoint the execution and process-design engines.

kubectl -n <namespace> exec -i --tty appian-service-manager-<engine>-0 -- ./serviceManagerScriptWrapper.sh services/bin/checkpoint.sh -s execution,process-design -w

Scale down the execution engine statefulset to 0.

kubectl -n <namespace> scale statefulset appian-service-manager-execution<XX> --replicas=0

(If the site is HA) Scale down the analytics engine statefulset to 1.

kubectl -n <namespace> scale statefulset appian-service-manager-analytics<XX> --replicas=1

Scale down the process-design statefulset to 0.

kubectl -n <namespace> scale statefulset appian-service-manager-process-design --replicas=0

Stop the analytics engine with the OOTB script from within each analytics engine pod.

kubectl -n <namespace> exec -i --tty appian-service-manager-analytics<XX>-0 -- ./serviceManagerScriptWrapper.sh services/bin/stop.sh -s analytics<XX>

Reset the analytics engine with the OOTB script from within each analytics engine pod.

kubectl -n <namespace> exec -i --tty appian-service-manager-analytics<XX>-0 -- ./serviceManagerScriptWrapper.sh services/bin/resetAnalytics.sh -s analytics<XX>

Scale all statefulsets back up to their desired number.

Classic Linux

Stop all app servers.

<APPIAN_HOME>/tomcat/apache-tomcat/bin/stop-appserver.sh

Stop the execution, analytics, and process-design engines.

<APPIAN_HOME>/services/bin/stop.sh -p <SM_PASSWORD> -s analytics,execution,process-design

Reset the analytics engine with the OOTB script.

<APPIAN_HOME>/services/bin/resetAnalytics.sh -p <SM_PASSWORD> -s analytics<XX>

Start the engines back up.

<APPIAN_HOME>/services/bin/start.sh -s analytics,execution,process-design

Start the app server.

<APPIAN_HOME>/tomcat/apache-tomcat/bin/start-appserver.sh

Affected Versions

This article applies to all versions of self-managed installations of Appian.

Last Reviewed: April 2026

Tags: self-managed, engines, infrastructure

KB-2375 How to Submit Issues and Change Requests for Appian Automated Testing Plugins (FitNesse, Cucumber, Selenium)

Kaushal Patel — Mon, 30 Mar 2026 16:18:38 GMT

Current Revision posted to Appian Knowledge Base by Kaushal Patel on 3/30/2026 4:18:38 PM

Purpose

The purpose of this article is to specify the information required to report issues or asking questions about appian-selenium-api.

Instructions

Please create an issue item for appian-selenium-api through GitLab issues.

Impact or reason for the change
Clarify what type of tests cannot be performed
Steps on how to recreate the issue
Any additional information, such as testing data or apps, that may help diagnose or resolve the issue

To contribute and resolve an outstanding issue, view the projects contributing.md file.

Note: Appian greatly appreciates all feedback on our product. However, please be aware that it is not our policy to provide information on when or how an enhancement request may be implemented in the product.

Affected Versions

This article applies to the latest version of Appian Selenium API.

Last Reviewed: March 2026

Tags: automated Testing, how-to, selenium

[DRAFT SUPP-2020] How to Submit Issues and Change Requests for Appian Automated Testing Plugins (FitNesse, Cucumber, Selenium)

Kaushal Patel — Mon, 30 Mar 2026 14:15:51 GMT

Revision 4 posted to Appian Knowledge Base by Kaushal Patel on 3/30/2026 2:15:51 PM

Purpose

The purpose of this article is to specify the information required to report issues or asking questions about appian-selenium-api.

Instructions

Please create an issue item for appian-selenium-api through GitLab issues.

Impact or reason for the change
Clarify what type of tests cannot be performed
Steps on how to recreate the issue
Any additional information, such as testing data or apps, that may help diagnose or resolve the issue

To contribute and resolve an outstanding issue, view the projects contributing.md file.

Affected Versions

This article applies to the latest version of Appian Selenium API.

Last Reviewed: March 2026

Tags: automated Testing, how-to, selenium

[DRAFT SUPP-2020] How to Submit Issues and Change Requests for Appian Automated Testing Plugins (FitNesse, Cucumber, Selenium)

Kaushal Patel — Mon, 30 Mar 2026 14:15:24 GMT

Revision 3 posted to Appian Knowledge Base by Kaushal Patel on 3/30/2026 2:15:24 PM

Purpose

The purpose of this article is to specify the information required to report issues or asking questions about appian-selenium-api.

Instructions

Please create an issue item for appian-selenium-api through GitLab issues.

Impact or reason for the change
Clarify what type of tests cannot be performed
Steps on how to recreate the issue
Any additional information, such as testing data or apps, that may help diagnose or resolve the issue

To contribute and resolve an outstanding issue, view the projects contributing.md file.

Affected Versions

This article applies to the latest version of Appian Selenium API.

Last Reviewed: February 2026

Tags: automated Testing, how-to, selenium

KB-2374 Update to Appian Forum Email Notifications - March 2026

Maggie Deppe-Walker — Sun, 29 Mar 2026 23:08:28 GMT

Current Revision posted to Appian Knowledge Base by Maggie Deppe-Walker on 3/29/2026 11:08:28 PM

Purpose

Appian Forum email notifications are used to notify shareholders of updates. This article outlines a change in the expected format of this communication going forward.

Upcoming changes

As of March 27th, 2026 the sender address for Appian Forum notifications will be updated.

Change Details

Previous Sender: forum@appian.com

New Sender: forum@forum.appian.com

Required Action

If you use automated inbox rules to manage these emails, please create an additional rule to now include the new address: forum@forum.appian.com.

Note: You will continue to receive non-notification correspondence, such as case updates or health checks analysis for instance, from forum@appian.com.

Last Reviewed: March 2026

SUPP-2374 Update to Appian Forum Email Notifications - March 2026

Ryan Good — Fri, 27 Mar 2026 18:29:42 GMT

Revision 8 posted to Appian Knowledge Base by Ryan Good on 3/27/2026 6:29:42 PM

Purpose

Appian Forum email notifications are used to notify shareholders of updates. This article outlines a change in the expected format of this communication going forward.

Upcoming changes

As of March 27th, 2026 the sender address for Appian Forum notifications will be updated.

Change Details

Previous Sender: forum@appian.com

New Sender: forum@forum.appian.com

Required Action

If you use automated inbox rules to manage these emails, please create an additional rule to now include the new address: forum@forum.appian.com.

Note: You will continue to receive non-notification correspondence, such as case updates or health checks analysis for instance, from forum@appian.com.

Last Reviewed: March 2026

[SUPP-2374] Update to Appian Forum Email Notifications - March 2026

Ryan Good — Fri, 27 Mar 2026 18:25:31 GMT

Revision 7 posted to Appian Knowledge Base by Ryan Good on 3/27/2026 6:25:31 PM

Purpose

Appian Forum email notifications are used to notify shareholders of updates. This article outlines a change in the expected format of this communication going forward.

Upcoming changes

As of March 27th, 2026 the sender address for Appian Forum notifications will be updated.

Change Details

Previous Sender: forum@appian.com

New Sender: forum@forum.appian.com

Required Action

If you use automated inbox rules to manage these emails, please create an additional rule to now include the new address: forum@forum.appian.com.

Note: You will continue to receive non-notification correspondence, such as case updates or health checks analysis for instance, from forum@appian.com.

Last Reviewed: March 2026

[Draft] Update to Appian Forum Email Notifications - March 2026

Ryan Good — Fri, 27 Mar 2026 14:53:02 GMT

Revision 6 posted to Appian Knowledge Base by Ryan Good on 3/27/2026 2:53:02 PM

Purpose

Appian Forum email notifications are used to notify shareholders of updates. This article outlines a change in the expected format of this communication going forward.

Upcoming changes

As of March 27th, 2026 the sender address for Appian Forum notifications will be updated.

Change Details

Previous Sender: forum@appian.com

New Sender: forum@forum.appian.com

Required Action

If you use automated inbox rules to manage these emails, please create an additional rule to now include the new address: forum@forum.appian.com.

Note: You will continue to receive non-notification correspondence, such as case updates or health checks analysis for instance, from forum@appian.com.

Last Reviewed: March 2026

[Draft] Update to Appian Forum Email Notifications - March 2026

Ryan Good — Fri, 27 Mar 2026 14:51:57 GMT

Revision 5 posted to Appian Knowledge Base by Ryan Good on 3/27/2026 2:51:57 PM

Purpose

Appian Forum email notifications are used to notify shareholders of updates. This article outlines a change in the expected format of this communication going forward.

Upcoming changes

As of March 27th, the sender address for Appian Forum notifications will be updated.

Change Details

Previous Sender: forum@appian.com

New Sender: forum@forum.appian.com

Required Action

If you use automated inbox rules to manage these emails, please create an additional rule to now include the new address: forum@forum.appian.com.

Note: You will continue to receive non-notification correspondence, such as case updates or health checks analysis for instance, from forum@appian.com.

Last Reviewed: March 2026

[Draft] Update to Appian Forum Email Notifications - March 2026

Ryan Good — Fri, 27 Mar 2026 14:51:04 GMT

Revision 4 posted to Appian Knowledge Base by Ryan Good on 3/27/2026 2:51:04 PM

Purpose

Appian Forum email notifications are used to notify shareholders of updates. This article outlines a change in the expected format of this communication going forward.

Upcoming changes

As of March 27th, the sender address for Appian Forum notifications will be updated.

Change Details

Previous Sender: forum@appian.com

New Sender: forum@forum.appian.com

Required Action

If you use automated inbox rules to manage these emails, please create an additional rule to now include the new address: forum@forum.appian.com.

Note: You will continue to receive non-notification correspondence - such as case updates, health checks analysis for instance - from forum@appian.com.

Last Reviewed: March 2026

[Draft] Update to Appian Forum Email Notifications - March 2026

kaddour.dima — Fri, 27 Mar 2026 14:40:24 GMT

Revision 3 posted to Appian Knowledge Base by kaddour.dima on 3/27/2026 2:40:24 PM

Important Update: Appian Forum Email Notifications

Starting March 27, email notifications from forum.appian.com will be sent from forum@forum.appian.com instead of the current forum@appian.com.

If you use automated inbox rules to manage these emails, please update them to include the new address: forum@forum.appian.com.

Note: You will continue to receive non-notification correspondence - such as case updates, health checks analysis for instance - from forum@appian.com.