Appian

The Process Owner

Forms with validation, validation groups and file upload, task inboxes, and node-level deadline and escalation settings are documented, and a running instance can be paused, edited structurally, patched only for that instance, or saved as a new minor version — which is exactly the discipline I need so a process change does not break the forty requests already in flight. Debug mode starts a process as a user would before it goes live, and the process history records executed actions. I found no public information on substitutes when an approver is on holiday, on four-eyes rules, or on assigning approvals to a role rather than a named person. 10 6 14

Report an error

The Integration Engineer

Forms are documented down to validation groups, file upload and encrypted text fields, task nodes carry assignee, priority, deadline and escalation settings that can be changed on the live instance, and a debug mode runs a process before it is published. In-flight editing is real: Apply Changes touches only the current instance while Save New Version writes a minor update to the published model. I found no public information on approver substitutes, four-eyes rules or rollback of a published process version, and the modelling notation is not identified as BPMN 2.0. 6 10 5

Report an error

The Operations Analyst

Forms with validation groups, file upload and pane layouts, node properties for assignee, priority, deadline and escalation, a debug mode to run a process before publishing, and editing of running instances with Save New Version semantics — plus documented major-version behavior that leaves existing objects untouched. We found no public information on BPMN or an equivalent documented notation, on role- or group-based approval assignment, substitutes or four-eyes rules; assignment shown is to individual assignees. 10 6 5

Report an error

The Head of IT

Forms are the strong suit — a documented form layout with validation groups, file upload and multi-column panes — and the process console lets a designer change assignees, priority, deadlines and escalation settings on running nodes, with a debug mode and per-instance edits before republishing as a new minor version. I found no public information on BPMN 2.0 or another documented notation, substitutes for approvers, or diff-and-rollback history for process models, which is what I would need before letting a business team maintain these alone. 5 6 10

Report an error

The Data Protection Officer

A running process is genuinely editable without breaking it: changes can apply to the single instance or publish as a new minor version, node properties carry assignee, deadline and escalation settings, and forms come with validation groups, file upload and a participant task list, with a debug mode for trial execution. We found no public information on the modelling notation, on substitutes, or on multi-stage approvals with a four-eyes rule, which is what the top of this scale asks for. 6 10 5 2

Report an error

The Skeptic

The documentation shows a real forms engine with validation, file upload and responsive layouts, task lists, deadlines with escalation settings, debug mode, and a clean separation between applying edits to one running instance and saving a new version of the model. We found no public information on approvers modelled as roles with substitutes or four-eyes rules, on a stated notation such as BPMN 2.0, or on diff and rollback for process versions, so this stops short of the governed-asset level. 5 6 10

Report an error

The Process Owner

The generic HTTP integration covers all common methods with proxy, timeout and error-handling override, SQL runs through a JDBC connected system with batching, web services support WS-Security, integrations can be built from OpenAPI descriptions or through a public Java API for custom plug-ins, and a self-managed edition on validated Kubernetes platforms can reach databases inside our firewall. I found no public information naming specific maintained connectors such as SAP or DATEV with their documented actions, on inbound webhooks, or on a documented public API to start and query workflows. 7 8 12 14

Report an error

The Integration Engineer

The integration object is what I want to see — every HTTP verb, JSON, XML and multipart bodies, configurable timeouts, proxy support and OAuth per connected system — backed by SQL over a JDBC connected system with batching, SOAP with WS-Security tokens through the web service smart service, custom plug-ins via a public Java API, and an engine that deploys fully on-premises so internal databases are reached without opening the firewall. The connector story is the letdown: the pricing page lists "Integrations 8" across tiers and names only Snowflake and Apache Kafka, with no connector's triggers and actions documented by name and nothing on DATEV, SAP or Dynamics. I found no public information on who maintains the connectors or on a documented public API to start and query workflows. 8 12 7 2

Report an error

The Operations Analyst

The machinery an integration team needs is documented: a generic HTTP integration with all common methods, timeouts, proxies and OAuth per connected system, OpenAPI-based integrations, SQL over a JDBC connected system, a web-service call with WS-Security, and a public Java API for custom plug-ins. But we found no public information naming which connectors exist with their supported actions or who maintains them, no inbound webhooks, and no connector for SAP, DATEV or comparable DACH systems named on the captured pages. 7 8 12 2

Report an error

The Head of IT

The generic machinery is genuinely good: documented HTTP, OpenAPI and SQL integrations, web-service calls with WS-Security, OAuth connected systems, a public Java API for custom smart services, and Cloud Secure Link for private connectivity at up to 500 connections per customer on Advanced and Premium. What I cannot verify is the catalogue itself — I found no public information naming the connectors, their supported actions, or who maintains them, and nothing on German-market systems like DATEV or SAP or on a versioned public API with a deprecation policy. 7 8 12 2

Report an error

The Data Protection Officer

Integration is engineered rather than a logo wall: a generic HTTP step covering the common verbs and content types, SQL over a custom JDBC connected system, SOAP calls carrying WS-Security UsernameToken, OpenAPI-based integrations and OAuth per connected system, with Snowflake and Kafka connectors named and tiered. We found no public information on connectors for Microsoft 365 or DACH ERP systems, on inbound webhooks, on an API to start and query workflows, or on who maintains each connector. 8 12 7 2

Report an error

The Skeptic

The generic machinery is genuinely documented: HTTP with eight methods, OpenAPI and SQL/JDBC integrations, SOAP calls with WS-Security, a public Java API for custom plug-ins, OAuth, and Cloud Secure Link for reaching systems behind the firewall, with the whole platform also runnable on-premises. But not one connector is named on the captured pages — no SAP, DATEV or Microsoft 365 — connector maintenance ownership is unstated, and we found no public information on inbound webhooks or a documented API to start and query workflows. 7 8 12 2

Report an error

The Process Owner

Live instances can be paused, resumed and cancelled, an errors tab shows active errors per process, node actions let an administrator change the assignee, deadline and escalations of a stuck step, and documentation covers automatic retry intervals alongside a published cloud SLA of 99.8–99.99% and high availability with 1 min RPO and as low as 4 min RTO, including a documented multi-replica setup for self-managed installs. I found no public information on failure alerts by email or chat, on execution-history retention per plan beyond a seven-day cap on HTTP request logs, or on replaying a failed run from the failing step. 9 10 2 14

Report an error

The Integration Engineer

Failures are surfaced properly — an Errors tab per process, integration outputs carrying result and error separately with an error-handling override, configurable timeouts, and HTTP request and response logging capped at 7 days and 100 MB with credentials masked — while the cloud side commits to a "99.8–99.99%" SLA, high availability at 1 min RPO and as low as 4 min RTO, plus horizontal pod autoscaling for self-managed installs. The captured facts are silent on automatic retries with back-off, on replaying a failed run from the failing step, on failure alerts by email or chat, and on a public status page with incident history. 10 8 2 2 14

Report an error

The Operations Analyst

Failures are visible and operable: an Errors tab per process, a Process History of executed actions, monitoring of archived processes, an automatic retry interval documented, configurable timeouts, a cloud SLA published at 99.8–99.99%, and high availability documented for self-managed installs with 1 min RPO and as low as 4 min RTO. We found no public information on failure alerts reaching email or chat, a searchable per-step execution log, execution-history retention per plan, or a public status page with incident history and credits. 10 9 8 2 2

Report an error

The Head of IT

Live-instance operations are documented properly: an errors tab, node-level pause, resume and cancel, per-instance edits and variable changes, and a documented automatic retry interval; high-availability replicas, autoscaling and a migration tool exist for self-managed Kubernetes installs. The captured pages give different figures for uptime — 99.95% on the homepage and a cloud SLA of 99.8–99.99% on the pricing page — and I found no public information on failure alerting, a searchable execution log with per-step input and output, runtime or rate limits, or a public status page with incident history. 1 2 9 10 14 2

Report an error

The Data Protection Officer

Failures are visible rather than silent — an Errors tab per process, Process History, configurable timeouts, graceful error returns from connector reads — and the HTTP log's copies of the payload are opt-in, truncated at 100,000 characters, capped at 7 days and 100 MB, masked of credentials and readable by system administrators only; a cloud SLA of 99.8–99.99% and high availability at 1-minute RPO are published. We found no public information on retry behaviour with back-off, on failure alerting, on replay from the failing step, on execution-history retention per plan, or on a public status page. 10 8 2 2

Report an error

The Skeptic

Instance monitoring is deep — errors, tasks and subprocesses tabs per instance, process history, debug runs, archived processes — and the pages publish a 99.95% uptime figure, a cloud SLA of 99.8–99.99%, and high-availability numbers with a multi-replica setup for self-managed installs. We found no public information on automatic retries and back-off, failure alerting, replay from the failing step, execution history retention per plan, or a public status page with incident history, which keeps 3 a.m. an open question. 1 2 10 14 2

Report an error

The Process Owner

Credentials sit in an encrypted secure credentials store, masked in the interface and never revealed, HTTP request logs are administrator-only with credentials masked and capped at seven days and 100 MB, SOC 1/2/3 and FedRAMP certifications are published, and Kubernetes role-based access control is documented in unusual depth. I found no public information on single sign-on via SAML or OIDC, on SCIM provisioning, on an exportable audit trail of who changed which workflow, or on configurable retention of execution payloads — the points our works council would raise first. 8 11 12 2

Report an error

The Integration Engineer

Credential handling is done right: the Secure Credentials Store encrypts values in the data source whether or not they are masked in the interface, keeps site-wide and per-user credentials separate, and strips encrypted values from exported packages in favour of environment-specific import files. HTTP logs are admin-only with Authorization headers masked and a stated 7-day, 100 MB cap, Process History records executed actions, and SOC 1, SOC 2, SOC 3 and FedRAMP are published. I found no public information on SSO via SAML or OIDC, SCIM provisioning, separate environments with a publishing approval, or an exportable audit trail describing what is recorded about individual users — and the role-based access page covers Kubernetes operator permissions, not workflow-level user rights. 12 8 2 11 10

Report an error

The Operations Analyst

Credential handling is genuinely solid — values encrypted and masked in the Secure Credentials Store, excluded from package exports, HTTP request logs accessible to system administrators only with credentials masked and capped at 7 days and 100 MB — and SOC 1/2/3 plus FedRAMP are published. But we found no public information on SSO, role-based permissions per workflow or folder, separate environments with publishing approval, an exportable audit trail describing the user fields it records, or execution-data retention beyond the HTTP logs; the RBAC documentation on offer covers the Kubernetes operator, not application users. 12 8 10 2

Report an error

The Head of IT

Credential handling is solid — the Secure Credentials Store encrypts values, masks them in the interface, separates per-user from site-wide credentials, and HTTP request logging is admin-only, capped at 7 days with credentials masked — and SOC 2 and FedRAMP attestations are published. But the role-based access documentation I found covers the Kubernetes operator, not application permissions per workflow or folder, and I found no public information on SSO via SAML or OIDC, an exportable audit trail of design changes and approvals, or controlled publishing between separate test and production environments — exactly the items I ask for before a department builds anything. 2 8 11 12

Report an error

The Data Protection Officer

From a data-protection seat this is the best-evidenced area: the Secure Credentials Store encrypts values and masks them in the interface, integration logging can be switched off per workflow and per console, truncates bodies, masks Authorization and credential headers, never outlives 7 days or 100 MB and is administrators-only, while Process History records executed actions and administrator roles gate start, pause and cancel. We found no public information on single sign-on, SCIM provisioning, separate environments with a publishing approval, an exportable audit trail, or which fields the trail keeps about individual employees — the record a works council asks to see — though SOC 1, SOC 2 and SOC 3 attestations are published. 12 8 10 2 11

Report an error

The Skeptic

Credentials get real treatment: encrypted in a secure credentials store, masked in HTTP logs only administrators can read, capped at 7 days and 100 MB, with a per-user versus site-wide credential model and encrypted values excluded from export packages. We found no public information on single sign-on, SCIM provisioning, separate environments with a publishing approval, or an exportable audit trail of design changes, and the SOC listings on the pricing page are the only certification evidence. 2 8 10 12

Report an error

The Process Owner

A self-managed edition runs on validated Kubernetes platforms with an operator, documented high availability and a migration tool from server-based installations, and objects export as packages. However, I found no public information on an export format another tool could read, on versioning definitions in Git, on the engine's licence terms, or on a migration path between cloud and self-hosted in both directions — and long-term licences are bound to the single site URL for which they were requested, which makes leaving harder than arriving. 14 2 14 8

Report an error

The Integration Engineer

Self-managed is engineered, not bolted on: a custom resource definition and operator with a Helm chart, validated on AKS, EKS, OpenShift, GKE, vSphere and bare-metal Kubernetes, a customer-chosen relational database inside or outside the cluster, multi-replica high availability, and a migration tool from the server-based installation. Portability of the work itself is weaker — definitions travel as the product's own packages with encrypted values excluded, and I found no public information on export as documented JSON or BPMN 2.0, Git versioning of definitions, or a documented path between cloud and self-hosted in either direction. Licences are bound to the site URL, long-term files take 4-5 business days to issue, and a new signing key arrives in November 2026. 14 14 2 8

Report an error

The Operations Analyst

A deeply documented self-managed Kubernetes edition — validated platforms, tested Kubernetes versions, required customer-provided database, multi-replica high availability, horizontal pod autoscaling, and a migration tool from server-based installs — alongside deployment in self-managed, hybrid cloud (AWS, Azure, Google) or on-premises. We found no public information on exporting workflow definitions in a documented format another tool could read, on versioning definitions in Git, or on a migration path between the cloud offering and self-managed; the engine ships under site-URL-bound proprietary license files. 14 14 2 8

Report an error

The Head of IT

Self-hosting is documented to an operations-grade level: a Kubernetes operator install with validated platforms and tested versions, a customer-provided relational database, high-availability replicas, autoscaling, and a migration tool from server-based installations. The exit is the weak part — export produces Appian packages with encrypted values stripped and environment-specific import files, and I found no public information on definitions in documented JSON or BPMN 2.0, Git versioning of definitions, an EU cloud region, or engine licence terms beyond site-URL-bound licence files that take 4-5 business days to issue. 8 14 2 14

Report an error

The Data Protection Officer

The engine runs where the customer chooses: self-managed Kubernetes with validated platforms, tested versions, a customer-provided relational database inside or outside the cluster, high-availability and autoscaling options, a migration tool from server-based installations, and licence mechanics documented down to the 6-day temporary key. We found no public information on exporting workflow definitions in a format another tool could read, on holding definitions in Git, or on a documented migration between cloud and self-hosted in both directions. 14 14 2 13

Report an error

The Skeptic

The self-managed story is documented to unusual depth: tested Kubernetes versions, validated platforms from AKS to bare metal, a customer-provided relational database, a migration tool from server installs, and multi-replica high availability through the operator. The portability side is thinner — we found no public information on an EU cloud region, on export of workflow definitions in a documented format another tool could read, or on versioning definitions in Git, and the engine runs on site-bound proprietary licence files rather than a published open licence. 8 14 2 14

Report an error

The Process Owner

The contracting entity is a US corporation, and I found no public information on where workflows and their logs execute, on selectable cloud regions, or on any subprocessor list; the published privacy policy explicitly excludes processing done in the role of processor for Appian customers, so it tells me nothing about our production data. A self-managed edition exists, but there is no statement that it runs without contacting the vendor, so I cannot credit it for data sovereignty either. 3 14 2

Report an error

The Integration Engineer

The contracting party is a Delaware corporation headquartered in Tysons, Virginia, and the captured pages say nothing about where cloud executions run, where their logs rest, or which subprocessors are involved — including the model providers behind the AI Actions and AI Agents sold per tier. The self-managed on-premises edition with the customer's own Kubernetes and database is the one sovereign path, but even there I found no statement that no licence or telemetry traffic leaves the customer's site. 1 2 2 14

Report an error

The Operations Analyst

Provenance shows a US corporation in Virginia, and the captured pages confirm neither an EU contracting entity nor an EU execution and log storage location; no subprocessor list and no location for the AI model providers behind the AI Actions appear on the captured pages. The published privacy policy states it does not apply where Appian processes personal data in the processor role for customers, so the buyer-facing data protection chain is unevidenced even though a self-managed deployment option exists. 3 2 2

Report an error

The Head of IT

The vendor information places Appian Corporation in Tysons, Virginia as a Delaware corporation listed on Nasdaq, and I found no public information on an EU contracting entity, EU execution or log storage, or a subprocessor list including the AI model providers behind the AI steps. The website privacy policy explicitly excludes processing done as a processor for customers, so the GDPR-style rights it lists say nothing about where workflows and their payload copies actually run. 2 3

Report an error

The Data Protection Officer

The chain of transfers cannot be located: the independently sourced provenance places the vendor in Virginia, USA, and the captured pages name no execution or log-storage region, publish no subprocessor list, and name no provider or location behind the AI Agents and AI Copilot steps, while the privacy policy expressly steps aside for processing in the processor role. The documented self-managed edition, with workflow data on the customer's own cluster and database, is the only stretch of that chain I can place, and it earns the single point. 3 2 14

Report an error

The Skeptic

The captured legal pages are silent on where workflows and their execution logs run, on subprocessors, and on which model providers sit behind the AI Agents steps whose monthly quotas the pricing page advertises, and we found no public information on an EU region or an EU contracting entity for a Nasdaq-listed US vendor. The one European-friendly fact is the well-documented on-premises edition, which counts only for the data that actually stays on the customer's own servers. 3 4 2

Report an error

The Process Owner

Tier names (Standard, Advanced, Premium), a per user, per month, per app unit and per-tier allowances such as 200K/500K/1M AI Actions per month and 5/25/unlimited RPA bots are public, and a free Community Edition for personal development exists. But I found no public price in any currency for any tier, nor for overages, premium connectors, additional environments, AI steps or the self-hosted licence — so the amount on our monthly invoice is not computable from these pages. 2 2

Report an error

The Integration Engineer

The tier structure is unusually open — Standard, Advanced and Premium "Priced per user, per month, per app", with AI Action allowances of 200K, 500K and 1M per month, bot counts of 5, 25 and unlimited, portal and Cloud Secure Link limits, and a free Community Edition. But the captured pricing pages give no price figure for any tier, and I found no public information on overages, minimum term or VAT treatment. The invoice remains a sales conversation with better documentation. 2 2

Report an error

The Operations Analyst

The pricing pages name three tiers and a model of per user, per month, per app, with public allowances such as 200K, 500K and 1M AI Actions per month and 5, 25 or unlimited RPA bots, plus a free Community Edition for personal development. We found no public prices in currency for any tier, and no information on overage, add-on or self-hosted licensing costs, minimum term or VAT treatment — the monthly invoice for a given workload cannot be computed from the public pages. 2 2

Report an error

The Head of IT

The billing unit is stated — per user, per month, per app — and tier allowances are public, including AI Actions of 200K, 500K and 1M per month for Standard, Advanced and Premium, plus RPA bot and portal limits. But neither capture of the pricing page shows a price for any tier, and I found no public information on overage pricing, premium connectors, the self-hosted licence, minimum term or VAT treatment — so the monthly invoice stays a sales conversation. 2 2

Report an error

The Data Protection Officer

The billing unit is stated — per user, per month, per app — and per-tier allowances are public, including AI Action limits of 200K, 500K and 1M per month, bot counts and portal limits. The captured pricing pages carry no monetary figure for any tier, and we found no public information on overage prices, premium connector costs, self-hosted licensing, minimum term or VAT treatment, so the monthly cost of a buyer's own processes is not computable. 2 2

Report an error

The Skeptic

The pricing pages are generous with quotas — AI Actions per month, bot counts, portals, row limits per tier — and name a billing model of per user, per month, per app, but we found no public prices in any currency for the Standard, Advanced or Premium tiers, no overage or add-on prices, no self-hosted licence price, and no definition of what counts as an app. Only the Community Edition has a public price, which is free for a personal development environment. 2 2

Report an error