https://community.appian.com/support/en-USTelligent Community 12https://community.appian.com/support/w/kb/3814/kb-2386-log-ingestion-pipelines-fail-for-login-audit-csv-after-upgrading-to-appian-25-4Mon, 15 Jun 2026 16:05:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:eb43299f-2fd7-450c-a67e-c2347d58d810pauline.delacruzSymptoms After upgrading to Appian 25.4, automated log ingestion pipelines (such as Splunk, Datadog, ELK, or custom Appian expression rules) that process the /logs/login-audit.csv file and rely on strict positional parsing or headerless formats may fail or parse data incorrectly. As a result, administrators may experience a temporary loss of login audit data visibility in downstream reporting stores, or trigger internal security/IT alerts due to these ingestion job failures. Cause This issue is caused by schema changes introduced in Appian 25.4 to support the new "Multi-Factor Authentication: Authenticator Apps" feature. Pipelines relying on headerless parsing or strict positional index mapping will fail due to two structural modifications: Inclusion of Headers : Row 1 of login-audit.csv now contains column headers. Historically, this file was headerless. New MFA Tracking Column : A new column was appended to the log to track native MFA events. In Appian 25.4, this column was initially introduced as MFA User . In Appian Hotfix 25.4.371.0, this column was renamed to MFA Authenticated and its behavior was refined to accurately distinguish genuine Appian MFA events from SSO/LDAP authentications. Note: true indicates successful authentication using Appian native MFA, while false indicates external authentication (SSO/LDAP), primary authentication failure, or MFA not being enabled. Strict positional parsing of the login-audit.csv file without accounting for the newly added header row is no longer a supported ingestion approach. For more information about login-audit.csv , refer to Logging . Action To resolve this issue and prevent future disruptions, log ingestion scripts and parsers must be updated: Account for the Header Row: Update ingestion scripts to ignore the first row as data, treating it instead as the schema definition. Update Parsing Logic : Switch from positional indexing to header-based mapping (e.g., map by the exact header string MFA Authenticated). This guarantees pipeline stability even if column orders change in future releases. Affected Versions This article applies to Appian 25.4 and later. Last Reviewed: June 2026integrationauthenticationhttps://community.appian.com/support/w/kb/936/kb-1575-how-to-enable-loggers-for-commonly-seen-appian-issuesThu, 04 Jun 2026 16:33:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:022de8fe-b261-4935-bc30-2205443c34c4Kaushal PatelPurpose In certain troubleshooting scenarios, it may be necessary to enable DEBUG logging to retrieve additional information related to the issue observed. This article details how to enable DEBUG logging for some of the most commonly seen issues in Appian. The DEBUG statements will be logged to the application server log, unless configured otherwise. Instructions Warning: Enabling the DEBUG logs in an environment can lead to large log files and introduce potential performance degradation. Appian Technical Support advises to enable loggers on lower environments before doing so on production. The steps to enable DEBUG logging are as follows: Open the appian_log4j .properties file. The location varies based on the version: For Appian 25.4 and later, edit the config map containing the appian_log4j_override.properties file . If this is the first time the logging is being used, please follow the documentation to generate the appian_log4j_override.properties file For Appian 18.3 and later, this file can be found in /deployment/web.war/WEB-INF/resources . For Appian 18.2 and earlier, this file can be found in /ear/suite.ear/resources . Find and uncomment the lines which apply to the particular issue you are trying to troubleshoot. Set the value of the line to DEBUG . Save and exit out of the file. The steps to disable DEBUG logging are as follows: Return to the appian_log4j.properties file, and update the lines you modified so that the value is changed from DEBUG back to ERROR . Save the file and check the application server log to verify that the DEBUG and TRACE log entries are no longer being recorded. When adding any of these loggers, check if they already exist in appian_log4j.properties , if they do, edit the existing line, otherwise add the lines to the appian_log4j.properties . Loggers: Appian Authentication, SAML, LDAP OpenID Connect User Authentication OAuth 2.0 Token Request Sequence Application Import/Export Appian Health Check CDT Import/Export Start Processes via Email Process Models Exposed as Web Service Process to Process Messaging Query Timeouts Query RDBMS Node Execution Capture SQL Statements using Hibernate Trace Logs SAIL Pink Box Errors Send Emails via the Send Email Smart Service Call Web Service Smart Service Importing Web Service CDTs Background activity in Appian Engines Details on CDT Transformation High Transformation Time When Processing the Results Received from the RDBMS Workpoller Issues Plugin Deployment XSD Validation for record types HTTP Connected System Request Executions Connected Environments DevOps Connected Environments (Retrieval of Public Keys) Compare and Deploy Inspection requests Salesforce Connected Systems Webserver logging Quick Apps Deployments stuck in progress Record Sync Incidents Appian Authentication, SAML, LDAP : log4j.logger.com.appiancorp.security=DEBUG log4j.logger.org.springframework.security=DEBUG log4j.logger.org.opensaml.core.xml.util=TRACE OpenID Connect User Authentication: log4j.logger.com.appiancorp.security.auth.oidc=DEBUG OAuth 2.0 Token Request Sequence: log4j.logger.com.appiancorp.connectedsystems.http.oauth.HttpOAuthTokenRetriever=DEBUG log4j.logger.com.appiancorp.connectedsystems.contracts.HttpOAuthTokenService=DEBUG log4j.logger.com.appiancorp.connectedsystems.http.execution.strategies=DEBUG log4j.logger.com.appiancorp.connectedsystems.http.oauth=DEBUG log4j.logger.com.appiancorp.oauth.inbound=DEBUG Application Import/Export : log4j.logger.com.appiancorp.ix=DEBUG Appian Health Check : Note: Only applicable when using the Health Check Plugin. These loggers do not apply when Health Check is configured through the Admin Console . log4j.logger.com.appiancorp.plugins.labs.BulkLogDownloadServlet=DEBUG log4j.logger.com.appiancorp.tools.labs.analysis.util.LabsFileFilter=DEBUG log4j.logger.com.appiancorp.healthcheck=DEBUG, HEALTH_CHECK CDT Import/Export : log4j.logger.com.appiancorp.type.external.teneoimpl.TeneoAnnotationsValidator=DEBUG log4j.logger.com.appiancorp.type.external.teneoimpl.AppianHbSessionDataStore=DEBUG Starting Processes by E-mail (email polling): log4j.logger.com.appiancorp.messaging.MessagePublisherServiceImpl=DEBUG log4j.logger.com.appiancorp.process.execution.service.ProcessExecutionServiceFacade=DEBUG log4j.logger.com.appiancorp.mdb=DEBUG Process Models Exposed as Web Services : log4j.logger.com.appiancorp.process.webservices.pmserver=DEBUG Process to Process Messaging : log4j.logger.com.appiancorp.messaging.MessagePublisherServiceImpl=DEBUG log4j.logger.com.appiancorp.process.execution.service.ProcessExecutionServiceFacade=DEBUG Query Timeouts : log4j.logger.org.hibernate.util.JDBCExceptionReporter=DEBUG Query RDBMS Execution and Validation : log4j.logger.com.appiancorp.process.runtime.activities.QueryRdbmsActivity=DEBUG log4j.logger.com.appiancorp.process.runtime.activities.JdbcActivity=DEBUG Capture SQL Statements : log4j.logger.org.hibernate.SQL=DEBUG log4j.logger.org.hibernate.type=TRACE SAIL (unmask pink pop-up errors) : log4j.logger.com.appiancorp.rest.shared.AppianExceptionMapper=DEBUG log4j.logger.com.appiancorp.core.expr.tree.Variable=DEBUG log4j.logger.com.appiancorp.core.expr.Parse=DEBUG Sending Emails with Send Email Smart Service : log4j.logger.com.appiancorp.process.runtime.activities.SendEmailActivity=DEBUG log4j.logger.com.appiancorp.ap2.mail=DEBUG Call Web Service Smart Service : log4j.logger.com.appiancorp.ws=DEBUG log4j.logger.org.apache.axis2=DEBUG log4j.logger.httpclient.wire.header=TRACE log4j.logger.org.apache.commons.httpclient=TRACE Importing Web Service CDTs : log4j.logger.com.appiancorp.type.config.xsd.SchemaFactory=DEBUG Background activity in Appian Engines : log4j.logger.com.appiancorp.process.background.EngineWorkSpringContextListener=DEBUG log4j.logger.com.appiancorp.process.background.EngineWorkControllerFactory=DEBUG log4j.logger.com.appiancorp.process.background.EngineWorkControllerRunnable=DEBUG log4j.logger.com.appiancorp.process.background.EngineWorkController=DEBUG Details on CDT Transformation : log4j.logger.com.appiancorp.type.xmlconversion=DEBUG log4j.logger.com.appiancorp.suiteapi.common.TypeConverter=DEBUG log4j.logger.com.appiancorp.core.data.converter=DEBUG High Transformation Time When Processing the Results Received from the RDBMS : log4j.logger.com.appian.perflogs.ecore-tv-conversion-trace=INFO, ECORE_TV_CONVERSION_PERF_TRACE log4j.additivity.com.appian.perflogs.ecore-tv-conversion-trace=false log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE=com.appiancorp.common.logging.AppianFileAppender log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE.layout=com.appiancorp.type.data.ecore.EcoreToTvConversionPerfLogger$TraceLayout log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE.File=${AE_LOGS}/perflogs/perf_ecore_tv_conversion_trace.csv log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE.MaxFileSize=10MB log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE.MaxBackupIndex=1000 log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE.encoding=UTF-8 Workpoller Issues: log4j.logger.com.appiancorp.ra.workpoller=DEBUG, WORK_POLLER Plugin Deployment: log4j.logger.com.appiancorp.process.admin=DEBUG XSD Validation: Note: This is used when record type validation fails or when deploying a plugin which constructs a CDT . log4j.logger.com.appiancorp.type.config.xsd=DEBUG HTTP Connected Systems Request Execution: Note: This is to check the request contents, how it was received, if response was received or timed out, etc. log4j.logger.com.appiancorp.connectedsystems.http=DEBUG log4j.logger.com.appiancorp.connectedsystems.http.execution.AppianHttpRequestExecutor=DEBUG Connected Environments DevOps: log4j.logger.com.appiancorp.connectedenvironments.logging.DevOpsInfrastructureHandlerAuditLogger=DEBUG log4j.logger.com.appiancorp.designobjectdiffs.functions.application.DodConnEnvCallSystemRuleHandler=DEBUG Connected Environment (Retrieval of Public Keys): log4j.logger.com.appiancorp.connectedenvironments.ConnectedEnvironmentPublicKeyRetriever=DEBUG log4j.logger.com.appiancorp.connectedenvironments.service.ConnectedEnvironmentsInitialRequestor=DEBUG log4j.logger.com.appiancorp.connectedenvironments.service.JwtUtils=DEBUG log4j.logger.com.appiancorp.connectedenvironments.KeyUtils=DEBUG Compare & Deploy (Inspection phase): Compare log4j.logger.com.appiancorp.designdeployments.handler.DplConnEnvAsyncInspectHandler=DEBUG log4j.logger.com.appiancorp.designdeployments.handler.DplConnEnvInspectHandler=DEBUG Salesforce connected Systems (returns error stacktrace returned by Salesforce): log4j.logger.com.appiancorp.connectedsystems.salesforce=DEBUG Webserver (returns data transferred to and from the servers when executing HTTP requests): Quick Apps: **these loggers are verbose, switch loggers to ERROR first before removing them from appian_log4j.properties file log4j.logger.org.apache.http=DEBUG log4j.logger.org.apache.http.wire=DEBUG Quick Apps: log4j.logger.com.appiancorp..object.quickapps.QuickAppObjectType=TRACE Deployment Stuck in Progress: log4j.logger.com.appian.kafka.KafkaTopicManager=DEBUG Record Sync Incidents: log4j.logger.com.appiancorp..record.data.recordloaders.ads.AdsReplicaTransaction=DEBUG log4j.logger.com.appiancorp.record.fn.RefreshReplicaForRecordTypeReaction=DEBUG log4j.logger.com.appiancorp.record.service.RecordReplicaUpdateService=DEBUG log4j.logger.com.appiancorp.record.service.quartz.ReplicaLoadJob=DEBUG log4j.logger.com.appiancorp.record.replicaupdate.LogRyowVsBulk=DEBUG log4j.logger.com.appiancorp.record.service.ReplicaSyncPollerImpl=DEBUG log4j.logger.com.appiancorp.record.service.quartz.scheduling.ScheduleManagerImpl=DEBUG log4j.logger.com.appiancorp.record.service.quartz.LoggingTriggerListener=DEBUG Affected Versions This article applies to all versions of Appian. Last Reviewed: June 2026loggingadministrationapplication serverhow-tohttps://community.appian.com/support/w/kb/378/kb-1161-http-1-1-413-request-entity-too-large-email-body-failed-to-render-errors-thrown-in-application-server-logMon, 01 Jun 2026 18:46:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:b8edb99a-6d49-4d2b-84a7-12ded5f033c8pauline.delacruzSymptoms Users may experience one of the following symptoms: Symptom 1 The HTTP File Upload Smart Service fails to upload files larger than 64KB (the threshold can be larger) with the following message in the application server log: com.appian.integration.httpclient.smartnode.HttpFileUploadSmartNode - ConnectorRuntimeException [title=HTTP error connecting to ##URL##, com.appian.integration.core.exception.ConnectorRuntimeException: HTTP/1.1 413 Request Entity Too Large] In the smart service’s output, an HTTP response code of 413 is returned. Symptom 2 Appian auto-generated email alerts are not sent by the server with the following error in the application server log: ... Caused by: java.io.IOException: Server returned HTTP response code: 414 for URL: XXXX Caused by: com.appiancorp.process.engine.EmailBodyException: Email body failed to render: MailBody{filename=/ntf/emailHtml/XXXX_emailHtml.jsp} Symptom 3 When a specific user performs an action that works for other users, like clicking on a form, task or report, they receive a generic error like one of the following: An internal error has occurred. The page could not be loaded. [HTTP Code = 413] (APNX-1-4279-001) The System Has Encountered an Error. HTTP Code: 413 The system has encountered an error. Please try again later. If using Apache, the following error can be observed in the mod_jk.log : [error] ajp_marshal_into_msgb::jk_ajp_common.c (469): failed appending the header value” in the mod_jk log. Symptom 4 The user experiences a HTTP 500 Error when navigating to: */suite/rest/a/applications/latest/app/design/monitoring : The following entries are printed to the tomcat-stdOut.log : com.appiancorp. rest .shared.FallbackExceptionMapper - Internal Server Error on REST API invocation. java.lang.IllegalArgumentException: Header message of length [x] received but the packetSize is only [ 8,192 ] at org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:636) at org.apache.coyote.ajp.AjpProcessor.receive(AjpProcessor.java:577) Cause This usually occurs because the web server has received a request that is larger than the configured limit. The web server is currently configured to limit the file size and will throw an error when it receives a request that is too large. Depending on the exact action being performed by the user, and the subsequent request being made to the web server, the error could be due to the size of the request’s header, message body or the total size of the request as a whole. Action To prevent this error from reoccurring, and to allow the requests to be fulfilled by the web server, raise the maximum allowed size for the area of the message (header, body, etc) that is causing the error. For Symptoms 1 and 2 When the size of the request’s body is too large: For IIS, the maxReceivedMessageSize parameter will have to be increased. By default, it is 64KB to prevent DOS attacks. For Apache, the parameter to be modified is LimitRequestBody . For Symptoms 3 and 4 When the size of the request’s header is too large: JBoss Add the following properties to the JBoss standalone.xml file under the tag: Restart the application server. Tomcat (Appian 21.2 and later) Add the following properties inside the custom.properties file, located in /conf . conf.appserver.ajp.maxPacketSize=24576 conf.appserver.maxHeaderSize=65535 Note that the default value for the maxPacketSize is set to 8192 and for the maxHeaderSize, the max is 66536. Restart the application server. Note : Remember to update these configurations in custom.properties. located inside /conf/ for future deployments. Tomcat (Appian 21.1) Add the following property inside the custom.properties file, located in /conf . conf.appserver.maxHeaderSize=65535 Note The max value for maxHeaderSize is 66536. Find the tag in the Tomcat server.xml file (Located in the directory \tomcat\apache-tomcat\conf ) for the AJP and HTTP protocol: Add the packetSize property to the AJP tag, the default is set to 8192 and the max is 65536: Restart the application server. Note : Remember to update these configurations in custom.properties. located inside /conf/ for future deployments. Tomcat (Appian 20.4 and earlier) Find the tag in the Tomcat server.xml file (Located in the directory \tomcat\apache-tomcat\conf ) for the AJP and HTTP protocol: Add the packetSize property to the AJP tag, the default is set to 8192 and the max is 65536. Add the maxHttpHeaderSize property to the HTTP tag, the max is 65536: Restart the application server. Additional Configurations if Using IIS as a Web Server Add the following property to the IIS workers.properties file (Located in the directory \conf ) matching the AJP value previously set in the server.xml file: worker.ajp13w1.max_packet_size=24576 worker.ajp13w2.max_packet_size=24576 Restart IIS. Additional Configurations if Using Apache as a Web Server In the Apache httpd.conf file (located in \conf ), update or add the following properties to align with your Tomcat AJP configuration values: Set the maximum HTTP header field size to match the Tomcat maxHttpHeaderSize value: LimitRequestFieldSize 65535 Set the AJP worker packet size to match the AJP maxPacketSize configured in Tomcat’s server.xml or Appian’s custom.properties : JKWorkerProperty worker. .max_packet_size=X where: is the Tomcat/AJP worker node name defined in your Apache configuration. X is the same value as your AJP maxPacketSize (for example, 24576 ). Save your changes. Restart the Apache web server for the new configuration to take effect. If Error Code 413 only occurs for one user please proceed with the following steps: Attempt to reproduce the issue while using the browser's Private/Incognito mode. If the issue cannot be reproduced in Private/Incognito mode, continue with step 2. If it the issue is still present, create a support case with Appian Support. Clear the cache and all cookies on your browser using the instructions provided in the browser documentation. Restart the browser and attempt to repeat the action that caused the 413 error. If the steps above do not resolve the issue and the user is on Internet Explorer, continue with the following steps: Select Tools > Developer Tools . Select the Console tab. Run the following string within the IE Dev Console: javascript:document.execCommand("ClearAuthenticationCache"); Press the Enter key. The following should be output on the console: Affected Versions This article applies to all self-managed versions of Appian. Last Reviewed: June 2026emailweb serverapplication server413infrastructurehttps://community.appian.com/support/w/kb/3709/kb-2385-plugin-review-security-scanning-faqWed, 27 May 2026 18:11:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:b7ea018d-4e92-4d29-9ed5-70cdc006dba9Ryan GoodAll plugins submitted to Appian for use on Appian Cloud require review and approval. This article aims to answer common questions about the plugin review process. For more information on plugin and AppMarket policies, refer to the AppMarket Submission Policies documentation and the AppMarket Submissions Agreement . Table of Contents: How are plugin security reviews performed? What specific tooling is used? How often are reviews performed? What happens to plugins that are flagged by security scans? Can Appian provide the scan results? What happens to plugins that are flagged by security scans? How long do I have to remediate a finding in my plugin? My plugin submission was previously approved. Why is my latest update not approved? I need to use my plugin on Appian Cloud ASAP. Can I bypass security review temporarily? How are plugin security reviews performed? Security scanning is first performed during all submissions of new and updated plugins to Appian. Subsequent reviews are also performed on a routine basis after initial approval. Scans such as Static Application Security Testing (SAST), Software composition analysis (SCA), and other security related checks are in place. What specific tooling is used? Appian utilizes custom tooling, open source software, and commercial off the shelf software to perform the automated security scanning. Appian does not publish the specific software used to review plugins. How often are reviews performed? Reviews are always performed upon plugin submission. Post-approval, additional security reviews are performed regularly. Appian reserves the right to perform security reviews at any time. Do security reviews apply to private plugins? Yes. As stated in the AppMarket Submission Policies , All plug-ins, whether intended for public use on the AppMarket or private use within an organization, must receive approval before deployment. Can Appian provide the scan results? Appian does not publish or share the results of security scans. Plugin authors are notified directly when one of their submissions is flagged by a security scan. What happens to plugins that are flagged by security scans? Plugin authors are notified directly when one of their submissions is flagged by a security scan. Plugins which are not updated may be removed from the AppMarket. Appian reserves the right to reject or stop hosting plug-ins at any time. How long do I have to remediate a finding in my plugin? Appian will provide a timeline for remediation when notifying you of a finding. Appian reserves the right to modify plug-in remediation timelines at any time. My plugin submission was previously approved. Why is my latest update not approved? Every submitted version of a plugin is reviewed in full. Approval of a plugin does not guarantee approval of subsequent versions. Appian reserves the right to modify plugin security policies at any time. I need to use my plugin on Appian Cloud ASAP. Can I bypass security review temporarily? Plugin submissions cannot bypass security review; only fully approved submissions can be deployed on Appian Cloud. If a plug-in requires expedited review, please include that context and justification in the submission. If you subscribe to a Signature Appian Success Plan, let your Lead Engineer know of your urgent request. Affected Versions This article applies to all versions of Appian. Last Reviewed: May 2026FAQpluginshttps://community.appian.com/support/w/kb/3815/kb-2384-appian-s-response-to-ai-accelerated-threats-mythos-daybreak-mdashWed, 27 May 2026 16:49:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:f09ad2d2-0775-49e8-9dcf-95ba4bf95069Kaushal PatelExecutive Summary Appian understands the concerns surrounding new, highly capable frontier models, such as Anthropic’s Claude Mythos Preview, and their potential to accelerate the discovery and exploitation of software vulnerabilities. Our position is that the core principles of robust cloud security continue to generate the most effective defense. Appian's security posture, built upon secure-by-design architecture, strict operational rigor, and deep partnership with Amazon Web Services (AWS), Chainguard, and others is actively managed to mitigate the risks introduced by AI-accelerated threats, ensuring the continued security and compliance of customer environments. What is Mythos? Claude Mythos Preview is a new large language model developed by Anthropic. It has demonstrated advanced capabilities in computer security tasks, particularly in identifying, analyzing, and potentially exploiting vulnerabilities in software. The critical industry insight regarding Mythos is not that it introduces fundamentally new vulnerability classes, but that it significantly reduces the time and expertise required for malicious actors to execute an AI-accelerated offensive, compressing traditional exploitation timelines. What is Daybreak? Daybreak is an OpenAI-developed frontier model, often discussed alongside Anthropic’s Mythos, associated with advanced AI reasoning capabilities. It is related to OpenAI's reasoning models like "o1" and "o3-mini" which are optimized for complex tasks such as programming. Like other frontier models, Daybreak's significance is its potential to accelerate AI-driven offense by making the discovery and exploitation of software vulnerabilities faster. What is MDASH? MDASH (which stands for Multi-model Dynamic/Agentic Scanning Harness or Multi-model Agentic Scanning Harness) is a highly advanced, AI-powered vulnerability discovery system developed by Microsoft . This system is designed for defensive use, rapidly identifying and addressing software vulnerabilities to help organizations 'defend at AI speed,' reflecting the industry-wide shift toward using AI to compress vulnerability discovery and exploitation timelines. This is what organizations today are doing relative to vulnerability discovery and remediation in code. Appian’s Perspective Appian’s position as a leading security organization is aligned with the community behind the Cloud Security Alliance (CSA) and Amazon Web Services (AWS): The appropriate response to AI-accelerated offense is an increased focus on foundational security controls. The CSA Mythos paper emphasizes that organizations must prioritize patch management, vulnerability remediation, and continuous monitoring to reduce the attack surface. Appian aligns with the AWS view that security is a shared responsibility, and that defense at scale requires continuous evolution of operational rigor, not reactive technology adoption. Our strategy is built on monitoring these developments and immediately integrating defensive learnings. We’ve gained perspective with the industry surrounding frontier models, including effective use of existing foundational models for security purposes. These tools are good at recursive reading and discovery; their findings will reflect your own organization's security maturity. If you have “skeletons” in the closet, don’t enforce MFA, don’t enforce a good SDLC, don’t upgrade to the latest patches, these are the equivalent of leaving your home unlocked and windows open for a burglar. We are actively engaged using tools available to us today, and take the opportunity that AI presents very seriously on behalf of Appian, you (our customers), and your customers. More on this below. Appian’s Position Appian’s approach to security is predictive, proactive, systematic, and aligned with the highest industry standards, providing essential mitigation against AI-accelerated threats. We jointly align with customers towards best practices to mitigate potential emergent threats and risks - AI or otherwise. Secure-by-Design Infrastructure Appian Cloud leverages the extensive security capabilities of AWS, relying on their expertise in securing the underlying cloud infrastructure. Our deep partnership ensures that Appian environments benefit from AWS’s scale, rigorous security controls, and immediate response capabilities. This includes leveraging identity and access management (IAM), network segregation, and continuous configuration checks provided by the cloud service provider. Frontier LLMs are good at finding security flaws within logic and code that when applied to standards, protocols, kernel, and supply-chains are the emergent threat fundamental to system operations; layering mature practices and response actions are required to keep pace. Differentiated Platform Architecture The Appian Platform architecture is fundamentally designed to reduce inherent risk and exposure: Zero-Trust: Appian's architecture is built on Zero Trust principles: never trust, assume breach, and verify every access request. This is implemented via a multi-control point lattice, shifting defenses from static perimeters to focus on users, assets, and resources. Core components include strong identity, device health, continuous re-authentication, hyper least privilege, and encryption everywhere. This resilient platform design provides consistent security regardless of user location or data sensitivity. Identity-Aware Access: All customer applications and data interactions are governed by a robust, fine-grained identity and access framework. Multi-Tenant Controls: Strong logical separation is enforced across all multi-tenant environments, isolating customer data and reducing the potential impact of a single vulnerability. Policy Enforcement and Auditability: The platform enforces strict security policies at every layer, providing comprehensive audit trails that enhance detection and response capabilities. Integrated Security Development: We leverage both deterministic and AI-assisted/agentic tools directly into our continuous integration pipeline to automatically flag and help developers remediate vulnerabilities before code is promoted. We are also adapting the frequency of AI-assisted secure code reviews for our entire code-base to proactively hunt vulnerabilities. Continuous 3rd party White-Hat Hackers and penetration testing are used to further enhance our posture. Our active investments in GenAI-driven security ensure continuous protection at the speed of development: AI-Powered Secure Design: We are augmenting security tools with additional AI-powered tools for architecture review and threat modeling to identify and fix flaws continuously in the agentic SDLCs, preventing issues before they are coded. Agentic Code Scanning: Security services in our SDLC have already been created as agent accessible tools to scan and remediate vulnerabilities directly inside developer environment tooling) and centrally enforced in code pipelines. Supply Chain Hardening: We are seeking additional hardened components similar to our use of Chainguard. We are migrating to private, vendor-managed third-party libraries and in our centralized artifact repository which governs all components, ensuring the integrity and provenance of our software supply chain against AI-accelerated attacks. Mature Vulnerability Management Program Appian maintains a mature, risk-based vulnerability management program that adheres to industry standards and regulatory expectations: Prioritization and Remediation: We leverage systems like CISA’s Known Exploited Vulnerabilities (KEV) database, and plan to include additional exploitability and reachability metrics to prioritize remediation based on real-world threat exposure, ensuring a focus on the most critical risks. Operational Rigor: Appian is committed to aggressive patching SLAs and maintaining Plan of Action and Milestones (POA&M) discipline. We are continuously improving our ability to rapidly deploy patches, specifically to meet the accelerated timelines suggested by AI-enabled offense. Supply Chain Security: To proactively counter supply chain risks, Appian is migrating to private, curated third-party libraries for components, ensuring all dependencies are current, patched, and malware-free. We partner with industry leading firms on pre-hardened and pre-patched assets in our supply chain where possible. Scaling Vulnerability Management: We are preparing for an order-of-magnitude increase in discovered vulnerabilities. Our processes leverage automation and advanced prioritization to streamline triage and enable rapid remediation of high-exposure findings. The Appian CSA Assessment In light of the evolving threat landscape, Appian has rigorously evaluated the risks and strategic guidance associated with frontier models, specifically aligning our internal assessments with findings from the Cloud Security Alliance (CSA) Mythos paper . We ensure our posture remains anchored in foundational operational rigor (e.g. systems hardening, mature vulnerability remediation, and rapid incident response), while simultaneously incorporating agentic AI technologies to modernize and accelerate our defensive capabilities. To reinforce Appian’s approach, our security investments (based on our risk assessments) are focused on: AI-Enhanced Secure Architecture: To ensure issues are mitigated before they reach the codebase, we are reinforcing our agentic SDLCs by integrating AI-driven tools for continuous threat modeling and architectural reviews. Agent-Integrated Vulnerability Scanning: We have transitioned security services into agent-accessible tools that operate directly within developer environments and are strictly enforced via central code pipelines to automate remediation. Robust Supply Chain Protection: Appian is actively strengthening our software supply chain by moving to private, vendor-managed artifact repositories and incorporating hardened components, such as Chainguard, to maintain rigorous integrity against AI-driven exploitation. Appian’s Offensive Defense: Turning AI-Accelerated Risk into Modernization Opportunity The greatest defense against AI-accelerated offense is a fundamental shift in application strategy. The Mythos model highlights a critical moment where organizations must move beyond defensive patching toward architectural security by default. Legacy or “vibe” code is now unsafe at any speed. Why & How with Appian: The speed of vulnerability discovery (now compressed to hours) means manual custom code development and patching cycles can no longer keep pace. Appian's low-code platform eliminates vast amounts of custom code, reducing the attack surface and enforcing secure patterns by design. Due to the insecure nature of AI vibe coding, enterprises should replace it with spec-driven development on secure platforms like Appian. Why & How with Appian: Relying on large language models (LLMs) to generate "vibe code" introduces new supply chain and vulnerability risks from potentially unvetted code. Appian's low-code, spec-driven approach generates standardized, secure code from certified platform components, ensuring integrity and auditability. Enterprises need to migrate custom and legacy apps to secure-by-default platforms like Appian. Why & How with Appian: Legacy apps are highly susceptible to this new shift. Appian provides a secure cloud architecture leveraging AWS's scale and security controls, offering continuous updates and a mature vulnerability management program. Secure platforms that reduce your attack surface and centralize patching and monitoring are the best way to reduce workload on security teams. Why & How with Appian: Moving applications to Appian Cloud shifts the burden of infrastructure security, patching (aggressive SLAs), and continuous monitoring to Appian and AWS. This drastically reduces the operational overhead and allows internal security teams to focus on core business risks. AI Agents need the guardrails and governance of secure process orchestration that Appian provides. Why & How with Appian: As autonomous AI agents become pervasive, constraining their actions is critical. Appian's process orchestration provides the necessary identity-aware framework, policy enforcement, and auditability to govern AI agents, ensuring they operate within defined, secure business processes. Customer Changes: Required Actions The speed of AI-accelerated threats requires immediate action to solidify your foundational security posture. We recommend customers prioritize the following actions: Accelerate Platform Updates: Promptly prioritize and schedule upgrades to the latest Appian platform releases to benefit from our continuous security enhancements and keep pace with vulnerability remediation. Reach out to Appian Support with your organization's desired posture; we recommend taking the latest release as soon as feasible for your organization. We can patch at the speed of your mission needs. Enforce MFA for All Accounts: With the release of additional MFA features in 26.1, audit your organizational requirements, ensure alignment and reach out to Appian Support if you need assistance. We recommend strong Multi-Factor Authentication (MFA) for all accounts (Appian or otherwise) to strengthen identity controls against AI-driven social engineering and credential misuse. Modernize on Appian Cloud: Eliminate critical attack surface by migrating all custom and legacy applications to the latest version of Appian Cloud, which offers secure-by-default architecture, centralized patching, and continuous monitoring. Adopt New Security Capabilities: Rapidly adopt key platform security features as they become available, such as Cloud Secure Link (when available) and Log Streaming (24.4/26.4) enhancements to meet your mission needs. Callout on Further Action: If additional, environment-specific action is required for your sites, our Solution Engineering team will reach out directly; ensure your security and admin contacts are up-to-date. Closing Statement Appian’s security posture is built keeping in mind the speed and scale of AI-accelerated threat discovery by frontier models. Our response strategy aligns with the industry, shifting to Zero-Trust and high-velocity operational rigor that prioritizes foundational security controls: vulnerability remediation, continuous monitoring, and continuous testing. This architectural approach is the essential alternative to risky “AI Vibe coding”; replacing ad-hoc code generation with spec-driven development using standardized, certified platform components to ensure security and auditability. Furthermore, Appian's secure process orchestration provides the necessary guardrails and governance to ensure pervasive AI agents operate securely within defined business processes, using identity-aware access and policy enforcement. Ultimately, our platform enables customers to quickly modernize legacy applications—which are highly susceptible to this new threat—on a secure, continuously updated architecture. This accelerated threat landscape requires a joint effort. To immediately strengthen your defenses and keep pace with AI-accelerated threats, we urge you to review and implement the Required Actions detailed above: Accelerate Platform Updates, Enforce MFA for All Accounts, Modernize on Appian Cloud, and Adopt New Security Capabilities. This article applies to all supported versions of Appian. Last reviewed: May 27, 2026https://community.appian.com/support/w/kb/3805/kb-2383-interactive-sail-examples-in-appian-documentation-fail-to-executeTue, 26 May 2026 16:01:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:ccf3435c-4466-4a35-a246-630f8545aec3pauline.delacruzSymptoms Interactive SAIL expression examples embedded in Appian documentation pages fail to execute. The browser displays the following error message: The connection is blocked because it was initiated by a public page to connect to devices or servers on your local network. This issue occurs in networks where the AWS API Gateway endpoint used by the documentation resolves to a private IP address. Cause Appian documentation pages use an AWS API Gateway endpoint with the domain *.execute-api.us-east-1.amazonaws.com to support execution of SAIL expressions. In enterprise networks AWS service endpoints may resolve to a private IP address. Modern browsers block requests where the originating page is treated as public and the target endpoint resolves to a private or local IP address. This is intentional browser behavior designed to prevent DNS rebinding and local network attacks. Action This is a known limitation that affects enterprise networks with private AWS networking configurations. Appian has added an enhancement to the documentation backlog to address this issue (Reference ticket: LCP-49998 ). No estimated time of availability is currently provided for this enhancement. Workaround Organizations may allow *.execute-api.us-east-1.amazonaws.com domains to resolve using public DNS controls to ensure the page loads properly. Affected Versions This article applies to all versions of Appian. Last Reviewed: May 2026web browserinfrastructureCloudhttps://community.appian.com/support/w/kb/3810/kb-2382-information-about-the-axios-supply-chain-compromiseWed, 13 May 2026 20:18:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:d49276b2-ef34-4bae-a832-6fb52350b0d5Kaushal PatelOn 11 May 2026, a coordinated supply chain attack was launched against the npm and PyPI ecosystems, targeting high-value developer tools and enterprise platforms. The campaign compromised a wide range of popular packages, including the @tanstack namespace (such as @tanstack/react-router ), the official mistralai clients for TypeScript and Python, and AI safety tools like guardrails-ai. 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: https://www.wiz.io/blog/mini-shai-hulud-strikes-again-tanstack-more-npm-packages-compromised https://socket.dev/blog/tanstack-npm-packages-compromised-mini-shai-hulud-supply-chain-attack https://www.aikido.dev/blog/mini-shai-hulud-is-back-tanstack-compromised Affected Versions This article applies to all supported versions of Appian. Last reviewed: May 13, 2026https://community.appian.com/support/w/kb/3795/kb-2381-how-to-fix-a-corrupted-database-table-index-using-phpmyadminThu, 07 May 2026 15:22:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:bbdad8ba-b20c-4c50-8c64-f110744d3ff8Kaushal PatelPurpose A corrupted index can make the associated table inaccessible. This can cause any queries, applications, or automated processes that rely on the table to fail until the index is repaired. This article outlines how to repair the affected index. Instructions Open the phpMyAdmin interface . Using the index definition from the table, drop and recreate the affected index using the following commands. Check the table to confirm the affected index: CHECK TABLE ; Identify the affected index and column information: SHOW CREATE TABLE ; Drop the affected index: ALTER TABLE DROP INDEX ; Recreate the affected index: ALTER TABLE ADD INDEX (cols); Confirm the issue was resolved: CHECK TABLE ; Affected Versions This article applies to all versions of Appian Cloud. Last Reviewed: April 2026phpmyadmindatabasehow-toindexhttps://community.appian.com/support/w/kb/1280/kb-1831-cloning-appian-cloud-sites-faqThu, 30 Apr 2026 13:55:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:c0d18e22-7d8e-4b4f-a566-647074efb4c0Kaushal PatelPurpose The purpose of this article is to answer common questions involved with cloning an Appian Cloud site for troubleshooting purposes. Table of Contents: What is a clone? Why does Appian Support request to create a clone? What data will be cloned? Who has access to the code/data hosted in the clone? Do clones have any impact on the host Appian Cloud site or other existing environments? How long is the clone and its data persisted? What is a clone? A clone is a replica of an existing Appian Cloud site. A new AWS instance is started, and a snapshot from an existing (host) Appian Cloud site is used to populate data on the new instance(s) creating a new separate site. All Appian Cloud clones are hosted in the same secure infrastructure as other Appian Cloud sites and are subject to the same security compliance protocols and controls. Why does Appian Support request to create a clone? Appian Support requests to clone a site for troubleshooting purposes. When investigating certain issues, it is sometimes necessary to test and debug directly to better understand the nature and scope of the behavior. In order to eliminate the risk of impact to an actual Appian Cloud site, it is necessary to run these tests on a clone of the environment. What data will be cloned? As a clone is created from a snapshot of a host site, all data as it exists at the time of the snapshot on the host site will be copied and present on the clone. For example, all Appian objects will be included, but not data hosted externally in customer databases. Who has access to the code/data hosted in the clone? Access to the code/data hosted in the clone is restricted to the following groups and is never shared with any third parties to ensure data integrity: Those who have access to the original Appian Cloud site. Team members from Appian Support and/or Appian's Product team that are involved in diagnosing and troubleshooting the issue(s) reported by the customer. Do clones have any impact on the host Appian Cloud site or other existing environments? No, clone sites exist separately outside of the host site and other existing Appian Cloud environments. Furthermore, outbound activity (emails, traffic, etc.) will be disabled as to not interfere with external systems. How long is the clone and its data persisted? The clone is persisted as long as the investigation into the current issue persists. Once the investigation is complete or no longer requires access to the clone, Appian will shut down the clone and delete its corresponding data. The clone can also be shut down at any time at the customer's discretion. Affected Versions This article applies to all versions of Appian Cloud. Last Reviewed: April 2026administrationSecurityinfrastructureCloudhttps://community.appian.com/support/w/kb/3069/kb-2284-how-to-deploy-plugins-on-a-kubernetes-appian-instanceWed, 29 Apr 2026 16:08:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:e638ea74-158b-4aca-8e3d-09abade8f174Ryan GoodPurpose Plug-ins are located in the directory /usr/local/appian/ae/_admin/plugins/ of the Webapp pod volume. This article describes how to deploy a plug-in to an instance of Appian on Kubernetes. Instructions Manually copy each plugin file into one of the webapp pods according to the documentation . Use the following template below: kubectl cp :/usr/local/appian/ae/_admin/plugins -n Example of deploying a plugin textutils-1.0.3.jar into a webapp pod named namespace : kubectl cp .\textutils- 1.0 . 3 .jar appian-webapp- 0 :/usr/local/appian/ae/_admin/plugins -n namespace If the instance is HA, run the command on one webapp pod. The plugin's directory will be mounted from the webapp RWX volume. Affected Versions This article applies to all self-managed versions of Appian in Kubernetes. Last Reviewed: April 2026webapphow-toKubernetespluginshttps://community.appian.com/support/w/kb/3806/kb-2380-information-about-the-apache-activemq-security-vulnerability-cve-2026-34197Wed, 29 Apr 2026 15:07:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:112c995e-4e87-4e0e-a566-f4afc8ac4265Kaushal PatelOn 17 April 2026, a critical vulnerability was discovered related to the Apache ActiveMQ software. This vulnerability involves improper input validation and code injection within the Jolokia JMX-HTTP bridge. An authenticated attacker can exploit this flaw by invoking management operations through the Jolokia API to trick the broker into fetching a remote configuration file, leading to arbitrary code execution (RCE) on the broker's Java Virtual Machine (JVM). Affected versions of Apache ActiveMQ Classic include all versions prior to 5.19.4 and versions 6.0.0 through 6.2.2. Appian has investigated this vulnerability and its services. While affected versions of Apache ActiveMQ are present within the Appian platform, we have confirmed that the Jolokia JMX-HTTP bridge and ActiveMQ web console are not used. Consequently, Appian services are not impacted by this vulnerability. As a proactive security measure, our engineering teams are currently upgrading these packages to the latest secure versions. We will continue to monitor the situation and provide updates as needed. Additional Notes: The following CVE was released with additional information on the scope of the vulnerability: CVE-2026-34197 - (Apache ActiveMQ Improper Input Validation / Remote Code Execution) Supporting Documentation: https://nvd.nist.gov/vuln/detail/CVE-2026-34197 https://thehackernews.com/2026/04/apache-activemq-cve-2026-34197-added-to.html https://www.helpnetsecurity.com/2026/04/09/apache-activemq-rce-vulnerability-cve-2026-34197-claude/ Affected Versions This article applies to all supported versions of Appian. Last reviewed: April 29, 2026https://community.appian.com/support/w/kb/3794/kb-2379-appian-cloud-self-service-alertsFri, 24 Apr 2026 14:43:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:e2e23ab3-d4f5-4ef4-b941-68eb7851ea0fKaushal PatelPurpose Appian's self-service alert functionality enables customers to manage specific environment alerts by providing the tools for immediate action. These alerts focus on customer-driven actions, allowing you to resolve issues directly without external dependencies. What are Self-Service Alerts? Self-Service Alerts provide immediate visibility into issues affecting your Appian Cloud environment, offering clear and actionable steps to resolve them on your own timeline. This functionality ensures faster resolution times, reduces the need for back-and-forth communication, and grants you greater control over your environment. Additionally, the ability to view both active and resolved alerts provides higher traceability for your cloud environment. This history allows you to track past issues and maintain a clear record of environment health and maintenance. Available Alerts Note: Appian continuously enhances our alerting capabilities as features evolve. This document is updated regularly to reflect these improvements. To stay informed, we recommend enabling notifications by selecting More > Turn Notifications On at the bottom of this page. You can also find the Last Reviewed date in the footer. Long Running Database Transaction Affected Versions This article applies to all versions of Appian Cloud. Last Reviewed: April 2026How Tohow-toalertsCloudhttps://community.appian.com/support/w/kb/3773/kb-2378-how-to-view-doccenter-version-in-appian-designerThu, 23 Apr 2026 19:50:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:5f02e4d3-3105-46b0-93e0-794faa1e2799pauline.delacruzPurpose This article outlines the steps on how to view the version of DocCenter your Appian environment may be using. Prerequisite To view the version of DocCenter on your environment, the user running through the steps below must have access to Appian Designer. Instructions To view the version of DocCenter on your Appian environment, follow the steps outlined below: Navigate to Appian Designer. Navigate to the DocCenter Application by searching for DocCenter in the "Applications" tab. Navigate to the "Build" Tab on the left-hand side. Click on constant under "Object Type" Search for AIA_VERSION The version should be visible in the following format under the Description column: - Note: Please see the documentation for more information on checking environment version compatibility with DocCenter. Affected Versions This article applies to all versions of Appian with DocCenter enabled. Last Reviewed: April 2026DocCenterintegrationhow-tohttps://community.appian.com/support/w/kb/762/kb-1447-appian-cloud-vulnerability-testingTue, 14 Apr 2026 15:29:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:99d81c09-22a3-4960-bd27-956b147956c1Kaushal PatelPurpose 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 2026SecurityCloudhttps://community.appian.com/support/w/kb/548/kb-1354-how-to-manage-high-disk-usage-in-appian-cloud-environmentsFri, 03 Apr 2026 14:31:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:527de8ca-e841-453a-92f8-6e8a7bf6d46bpauline.delacruzPurpose 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. Actionable Components Knowledge Centers & Documents Logs RDBMS Data Archived Processes & Process History Engine Transactions and KDBs RPA Executions RPA Logs 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 /suite/design/ . Click on the Objects tab. Filter by the Folder object type. Type in the search bar, where 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. T o 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. T o 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 /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 2026administrationhow-todisk usageCloudhttps://community.appian.com/support/w/kb/3792/kb-2377-information-about-the-teampcp-canisterworm-supply-chain-compromiseThu, 02 Apr 2026 17:24:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:2b641df6-4046-4163-8fdb-477ef1c73152Kaushal PatelIn 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: https://www.endorlabs.com/learn/teampcp-isnt-done https://www.mend.io/blog/canisterworm-the-self-spreading-npm-attack-that-uses-a-decentralized-server-to-stay-alive/ Affected Versions This article applies to all supported versions of Appian. Last reviewed: April 2, 2026Securityhttps://community.appian.com/support/w/kb/3791/kb-2376-information-about-the-axios-supply-chain-compromiseWed, 01 Apr 2026 20:38:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:33a29212-f81a-4bc5-a233-f241e0302302Kaushal PatelOn 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: https://snyk.io/blog/axios-npm-package-compromised-supply-chain-attack-delivers-cross-platform/ https://www.mend.io/blog/poisoned-axios-npm-account-takeover-50-million-downloads-and-a-rat-that-vanishes-after-install/ Affected Versions This article applies to all supported versions of Appian. Last reviewed: April 1, 2026Securityhttps://community.appian.com/support/w/kb/374/kb-1157-how-to-reset-the-analytics-engines-for-self-managed-installations-of-appianWed, 01 Apr 2026 16:43:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:715fa449-6f10-469e-b6df-b3f710610ab4pauline.delacruzPurpose 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 scale statefulset appian-webapp --replicas=0 Checkpoint the execution and process-design engines. kubectl -n exec -i --tty appian-service-manager- -0 -- ./serviceManagerScriptWrapper.sh services/bin/checkpoint.sh -s execution,process-design -w Scale down the execution engine statefulset to 0. kubectl -n scale statefulset appian-service-manager-execution --replicas=0 (If the site is HA) Scale down the analytics engine statefulset to 1. kubectl -n scale statefulset appian-service-manager-analytics --replicas=1 Scale down the process-design statefulset to 0. kubectl -n 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 exec -i --tty appian-service-manager-analytics -0 -- ./serviceManagerScriptWrapper.sh services/bin/stop.sh -s analytics Reset the analytics engine with the OOTB script from within each analytics engine pod. kubectl -n exec -i --tty appian-service-manager-analytics -0 -- ./serviceManagerScriptWrapper.sh services/bin/resetAnalytics.sh -s analytics Scale all statefulsets back up to their desired number. Classic Linux Stop all app servers. /tomcat/apache-tomcat/bin/stop-appserver.sh Stop the execution, analytics, and process-design engines. /services/bin/stop.sh -p -s analytics,execution,process-design Reset the analytics engine with the OOTB script. /services/bin/resetAnalytics.sh -p -s analytics Start the engines back up. /services/bin/start.sh -s analytics,execution,process-design Start the app server. /tomcat/apache-tomcat/bin/start-appserver.sh Affected Versions This article applies to all versions of self-managed installations of Appian. Last Reviewed: April 2026self-managedenginesinfrastructurehttps://community.appian.com/support/w/kb/3751/kb-2375-how-to-submit-issues-and-change-requests-for-appian-automated-testing-plugins-fitnesse-cucumber-seleniumMon, 30 Mar 2026 16:18:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:9f0e1645-b513-45ea-a753-e9f240521c1eKaushal PatelPurpose 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 2026automated Testinghow-toseleniumhttps://community.appian.com/support/w/kb/3788/kb-2374-update-to-appian-forum-email-notifications---march-2026Sun, 29 Mar 2026 23:08:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:327fcec1-02e0-4c3c-9287-bb1d14e554c1Maggie Deppe-WalkerPurpose 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