The Appian Process Modeler makes it easy to integrate your enterprise processes into your applications. Using different process nodes and smart services, you can execute business rules, manipulate data, automate processes, and more.
There are cases though when your process model may return an error, or they may not execute as expected. When either of these situations occur, use this page to learn why they happened and possible ways to resolve the issue.
There are two types of issues that can occur within a process model:
Process errors can be caused an issue with the process properties that affect the entire process model, or they can be caused by an issue within a single node. The most common issues are typically a result of insufficient privileges, invalid node or expression configuration, or an evaluation timeout on a node.
These errors will trigger an email alert so specific users (like your system administrator or administrators of the process model) are notified about the problem in your process. The email will contain a link to the process instance’s error in the Monitor view so you can view where the problem occurred, why it happened, and when.
Tip: You can customize who is notified of process errors from the Alerts tab of the process model properties.
When a node triggers a process error, the process will pause at that node and cannot continue until an administrator troubleshoots the issue. Most issues will occur in your development environment and can be addressed by changing the configuration of your process model and restarting the process model.
However, there are also some errors that can occur in your production environment. In these instances, it may be necessary to modify the process in-flight and restart or resume any affected nodes. This allows the process to continue and doesn’t require restarting the entire process from scratch.
See the Issues that return process errors section below for more information on the different types of issues and their possible solutions.
There are cases, though, when there are no process errors, but the process model still didn’t execute as expected. For example, a process model assigns a specific user to a task, but the user can’t see the new task. Or perhaps a gateway didn’t send a workflow to the appropriate outflow.
When these types of issues occur, it’s likely a result of an incorrect configuration somewhere in your process. In the examples above, the issues could stem from a missing process variable, the user not having permission to view the interface, or perhaps the data was just entered wrong.
We’ve provided a list of possible issues you could run into during development that do not trigger errors in the Unexpected issues that do not return process errors section below.
The following section describes some possible process errors and ways to resolve them. This is not an exhaustive list, but it covers some of the most common errors that you may encounter.
To quickly see all process errors that have occurred in your application, go to the Monitor view in your application and select Process Activity. Here you can see a list of all unresolved process errors, and choose to review resolved process issues as well.
Tip: A process error is resolved when the process is completed or canceled, or if you manually start a process from a paused node and it succeeds.
Every node is evaluated in the context of a user. This means that if a node is started by a user that does not have the appropriate permission to perform a node’s action, that node will throw an error.
For example, let’s say a user has permission to start a process that creates a folder within a knowledge center, but that user does not have permission to that knowledge center. In this case, the process would error on the node that creates the new folder.
Ensure that any objects referenced in your process model (like a record type, group, or expression rule) have the appropriate object security, including the process model itself.
For a user to start the process model, they must have at least Initiator permissions. If a process is triggered by a timer or as a subprocess, it will be executed as the user who deployed the process model into production. As such, make sure this user account has the appropriate permissions on all objects referenced within the process model.
Review the process model security to ensure all appropriate users can start and interact with the process, or use the Modify Process Security Smart Service to give a user the appropriate permissions via a process.
Additionally, you should review the security role map for each object involved in your process to ensure users have the appropriate level of permission. In the example above, this would mean that users need at least Editor permissions to modify objects within a knowledge center.
See Object security to learn more.
In addition to object-level security, users must also be the appropriate user type to complete certain tasks.
For example, if the initiator of the process is a Basic User, but the process uses the Remove Group Members smart service—which requires that the user be a System Administrator—the process will error.
Ensure that only users who are System Administrators can access processes that involve user creation, modification, or deletion.
Process models are often used to add new data to a database using the Write Records, Write to Data Store Entity, or Write to Multiple Data Store Entities smart services.
But, a write operation could fail for the following reasons:
Note: If you are updating data that is used as the source of a record type with data sync enabled and the smart service fails, the record data will be unavailable until the next successful full sync.
To ensure your smart services successfully write to your database:
@Column JPA annotation with the length attribute in your CDTs to control the maximum number of characters a column can hold.Similar to other design objects in Appian, process models frequently use expressions. If there is a runtime error, where the expression is valid but there are invalid rule inputs or parameter values, it can cause a process error.
These errors can occur in any configuration within a process node or in the process model properties, but they most commonly occur within the input or output of a node.
Expression evaluation errors are often caused by issues such as:
a!save(), custom field functions, or smart service functions.Each expression evaluation error will return an error message with details on how to resolve the error. You can often resolve the error by replicating the error within an expression rule and determining what expression changes will fix the error.
Some process nodes require a value for certain inputs or require a certain type to ensure the node executes correctly. For example, the records node input of the Write Records smart service requires an input of type Record Type.
If no value is provided or the wrong type is provided, the node will pause and cannot continue until the issue is corrected.
Review the node to identify if any inputs are required. Required inputs always appear with an asterisk (*). Also check to see what input is used for the node and ensure the value you provide matches it or can be cast to the correct type.
If an object does not exist when the process tries to reference it, the process will pause by exception. For example, if a script task references a group that was deleted earlier in the process, the process will pause.
Many objects in Appian can cause this issue, including:
Make sure your expressions and configurations point to objects that exist. Also when deleting objects, make sure there aren’t any dependencies before deleting the object.
Multiple node instances is a property that allows a node to be executed multiple times to achieve parallelization, such as sending tasks to many users at once. The property requires an additional configuration to identify how many times to execute the node. If the number of nodes to execute is 0 (possibly because an expression evaluates to 0), the node will pause.
Make sure the number of nodes to execute is always greater than or equal to one. You can add a gateway before the node to execute to check that at least one node will be executed. If not, the gateway can be set to skip the node.
The following section describes some issues you may encounter when building your process and ways to resolve them. The issues below will not return a process error and are likely a result of incorrect configuration somewhere in your process.
If required process information is missing or invalid, you won’t be able to start the process model.
For example, if a required process variable is not provided a value, or an expression evaluation occurs in a required process configuration, then you will not be able to start the process.
Review all required process information, like process properties, process variables, and default alerts.
Although this issue will not trigger a process error, you will still receive an error message that contains more information about the issue and specific resolution steps.
Tasks can be assigned to a single user or a group of users. If a task is assigned to a user, but that user cannot see the task, it may be because:
To ensure the assigned user can see their task:
If a user is receiving an error when they try to open a task, it’s likely due to an issue with the interface or how the interface is connected to the task.
For example, the form could be mapped to a value that does not exist. Or, perhaps there is an error within the interface that is preventing it from rendering.
To ensure users can open the task:
Gateway nodes allow you to evaluate different criteria to make decisions on which path your workflow should follow. When a gateway does not send a workflow to the expected outgoing path, the problem may be:
To ensure the gateway sends the process to the correct outgoing path:
pv!value > 5 and pv!value > 10 since a value of 15 would still cause the first condition to execute.If a gateway node is configured incorrectly, the gateway could end up with no paths to execute and the process will pause indefinitely.
This usually occurs for one of two reasons:
To ensure a gateway successfully completes:
When working with subprocesses, setup is required in both the parent process model and the subprocess.
If either of the following is true, then your subprocess may not work correctly:
To ensure the activity in a subprocess receives the parent’s values:
The Write Records, Write to Data Store Entity, and Write to Multiple Data Store Entities smart services are all able to create and update data in a database. However, If the smart service is creating data when you expect it to update existing data, it's likely because the record or value being passed to the node does not have a value set for the primary key field.
To ensure you are updating existing data instead of creating a new row of data:
If you have made changes to your process model, but those changes aren’t appearing when you start the debugging process or when an end user runs the process, it’s likely because the process model hasn’t been published since the changes were made.
Alternatively, someone else may have published a new version of the process model than the one you’re running. Luckily, both have an easy fix.
To have your process changes appear when running the process:
When you configure your sites, you have the option to add actions as a page type. This page type allows users to initiate a process, like submitting a new service request.
If you cannot select a specific process model for your action, it’s because there is no start form associated with that process model.
Actions can only be used in a site if the process model has a start form. This is because the form will show up when an action page is selected. Either modify your process model to include a start form, or choose a different process model.
Usually when starting an action, a user will complete information on a form required for the process. However, if the start form does not display it may mean that the user input task is not set up correctly.
To ensure the form appears when starting the action, review the start form configuration in the Process start form tab of the Process Model Properties dialog.
If you're using a User Input Task, make sure there is activity chaining between all nodes from the start form to the user input task.
If you expect a node to execute but the process continues on without completing it, often the node is not property connected or the process model has not been published.
Make sure the node is actually connected. In the image below, notice that the script task does not have an arrow entering the node. This occurs because the node is above the path but is not actually connected to it.
Additionally, make sure the process model is published. This ensures the process executes with the latest version, which should contain any node updates.
To publish a process model:
When a process flow reaches a node, the node will attempt to execute and it should show as green when it is active. However, there are a few reasons that the node could delay starting, such as being scheduled or a condition for starting has not been met.
Check to see if the node has been scheduled for a future time. The node will not start until that time is met.
Also remember that the time it is executed depends on the time zone of the process model, which is usually inherited from the default time zone of the designer of the process model.
In order for a process to complete, all active flows must reach an end node. This means that if there are multiple active flows, the process is still considered active even if only one of them reaches an end node.
First ensure that the process is configured to have all active flows reach an end node.
You should also add a Terminate trigger on your end node. When using this trigger, any node that reaches this end node will complete the process, even if there are other active flows.
Tip: It's recommended to set most end nodes to terminate unless the process specifically expects to have multiple active flows.
The outputs of a node are used to capture changes from the node and persist the results into process variables that can be used later on in the process. However, if the inputs or outputs are misconfigured, the output may not save the correct data.
When saving data into a variable on the output, make sure the same variable is not also being updated by the Save Into parameter on the input. When the node completes, the results from the inputs tab are saved after the results on the outputs tab.
If you have a custom output, make sure the output expression is returning the correct result. It’s often helpful to test this expression in an expression rule outside of the process model.
