Process - Recent Threads

Receive Message Node Not Triggering DocCenter Extraction Model

n_vdl — Thu, 14 May 2026 10:14:10 GMT

The Receive Message node has been configured to receive incoming emails that should trigger one of the extraction models within DocCenter.

However, this is not happening. Instead, the system only stores the document uploaded or attached to the email within the folder shown in the screenshot.

There is also nothing appearing in the system logs from what can be seen. It is unclear what may be missing, possibly a plug-in, as the attachments functionality within the Receive Message node has been deprecated.

Sending emails is breaking the chain of activities

AlexanderFlores — Sun, 10 May 2026 00:16:36 GMT

Okay, I have a process flow that goes like this: a person enters an interface to reassign a case, maps the emails, etc. Then they enter a synchronous subprocess that connects to an API. Depending on the validation (whether the user clicked "assign" or "reassign"), an asynchronous process runs that sends an email notifying them that the case has been reassigned. The requirement is that after this is done, the user returns to the main screen. The flow works when the email isn't involved, but when the email is, even though it's asynchronous, the activity chaining breaks. Could you help me find a solution for this, or suggest other options? Thanks!

RE: Sending emails is breaking the chain of activities

AlexanderFlores — Mon, 11 May 2026 16:58:28 GMT

As Rocky from Project Hail Mary would say: "Amaze, amaze, amaze!", using `Start Process` from the interface allows for a faster workflow and prevents the interface from breaking. Thank you so much, community!

RE: Sending emails is breaking the chain of activities

Mike Schmitt — Mon, 11 May 2026 16:30:23 GMT

I believe Stefan already mentioned this but just tp specify, your "Assign" subprocess is running synchronously but drops chaining in the first flow line.

RE: Sending emails is breaking the chain of activities

Shubham Aware — Mon, 11 May 2026 05:40:57 GMT

Use the Start Process smart service node to trigger the email process, It fires it as a completely separate process instance. Place it after the user-facing chain completes so it doesn't interfere with activity chaining.

https://docs.appian.com/suite/help/26.3/Start_Process_Smart_Service.html

RE: Sending emails is breaking the chain of activities

Stefan Helzle — Sun, 10 May 2026 07:02:27 GMT

Did you consider using the "Start Process" smart service instead of "Subprocess"?

You second process model breaks chaining as it misses the chain from the start node to the XOR.

RE: Process Variable Consistency Across Parallel Flows and Exception Handling in Appian

Harsha Sharma — Sat, 02 May 2026 14:29:55 GMT

When the flow reaches the user input task in Branch B, depending on whether pv!x was already updated in Branch A or not the value passed to task node will vary.
1. If pv!x is updated to 6 before user input task started then branch B will pass 6 to the task

2. If pv!x was not updated to 6 and user input task starts in Branch B then 5 will be passed to the task.

3. In both the cases however as soon as branch A updates the pv!x to 6 Branch B will see the updated value as the variable referenced is the common and not a copy or reference.

Overall in terms of value passed to task depends in timing of the flow in parallel. But in process at any point of time or Branch, pv will hold one value only - 5 or 6! Child nodes can have older or newer value depending on the sequence they occur.

Process Variable Consistency Across Parallel Flows and Exception Handling in Appian

enriquec149 — Thu, 30 Apr 2026 12:09:50 GMT

Hi all,

I have a question about process variables behavior in parallel flows and exception handling.

Scenario:

- The parent process has a process variable (pv!x) initialized with value = 5.

- The process splits into two parallel branches.

- Both branches start with pv!x = 5.

Then:

- Branch A continues execution, updates pv!x, and reaches the merge point.

- The parent process continues and later updates pv!x = 6.

- Meanwhile, Branch B is still active and waiting in a task (for example, a user input or a task with an exception flow handling an error).

Question:

Will Branch B see the updated value (pv!x = 6) while it is still in that task/exception state, or will it continue working with the original value (pv!x = 5) that was evaluated when the branch started?

In other words:

Are process variables dynamically re-evaluated for already running parallel activities, or do they keep the value from the moment the activity started?

Thanks in advance!

RE: Process Variable Consistency Across Parallel Flows and Exception Handling in Appian

manojtumulu — Fri, 01 May 2026 21:09:23 GMT

Within a single process model, process variables (PVs) are global in scope. So, if Branch A updates pv!x to 6, then Branch B will see pv!x = 6, assuming the update has already occurred, because both branches are working on the same shared process state.

However, when you introduce a subprocess (child process) in a branch, the behavior is different. At the moment the subprocess starts, it receives a copy of the process variable values from the parent.
If pv!x is still 5 at that time, the subprocess will receive 5, even if the parent updates pv!x to 6 later.

Therefore, subprocess interactions behave like pass-by-value, not pass-by-reference. Because:
The child process receives a snapshot of the data at invocation time and It does not automatically see future updates made in the parent process.

RE: Process Variable Consistency Across Parallel Flows and Exception Handling in Appian

Stefan Helzle — Fri, 01 May 2026 16:27:53 GMT

What exactly do you mean with "branch" and "parent process"? Is this about a single model with a AND or XOR flow?

RE: Process Variable Consistency Across Parallel Flows and Exception Handling in Appian

Shubham Aware — Thu, 30 Apr 2026 15:40:44 GMT

Branch B will see pv!x = 6.
Process variables are shared across the entire process instance - not scoped per branch. When any branch (or node) updates a PV, the change is immediately visible to all other active branches, including Branch B, even if it's mid-task or in an exception flow.
PVs are global to the process instance.

RE: Process Model

Chris — Wed, 29 Apr 2026 15:36:12 GMT

I also like to use subprocesses for any logic that I want to take effect for running instances, as well as new, as soon as the code change is deployed. This is especially helpful in 'longer running' processes, but also comes in handy for some quicker processes.

Email notifications is one scenario - we find the business often updates email instructions or directions, etc, where you want ALL new notices to contain the new verbiage. If the notification is at the end of your parent process, legacy instances will continue to send the legacy notices, unless they are configured via subprocess.

Other than email notices, audit doc creation, etc, we primarily use subs to separate logic for process model sizing and cleaner development.

While I do regularly have subprocess re-used / re-called within the same process model (think, audit doc update that is called each time the process progresses), it is much more rare that we have a subprocess shared between separate applications.

Process Model

diyar185976 — Fri, 24 Apr 2026 18:25:42 GMT

How do you decide between using subprocesses and keeping everything in a single process model?

WEB API process model restart and error handling

maithrih0093 — Thu, 23 Apr 2026 19:35:00 GMT

I have a web API which expects post request and provides the response after completing few important nodes and other actions are configured Asynchronously . Asynchronous process involves copy document, send data to second external system which are wrapped as multiple subprocesses. Now let's say if any of these asych process fails and I notify the first external system along with process ID, is there a way possible to retrigger the appian broken instance again (ignore the failure reason)? if not can I restart from the broken node itself? does appian provide this capability?

(Plugins: Get Processes By Node Status and process-management-services doesn't seem to be working as expected for my case)

RE: WEB API process model restart and error handling

Shubham Aware — Tue, 28 Apr 2026 11:16:34 GMT

No. Does not support programmatically resuming a failed process instance from the broken node.
Only option natively: Manual retry via Process Monitor.

Practical workaround: Store async subprocess inputs in a DB -> on failure, expose a retry endpoint that re-invokes only the failed subprocess using stored inputs.

RE: Process Model

Shubham Aware — Tue, 28 Apr 2026 06:09:07 GMT

Use subprocesses when logic is reusable, independently testable, or makes the main process too complex to read.
Keep everything in a single process when the flow is simple, linear, and not reused elsewhere.
A good signal for a subprocess is if it represents a distinct business function like approvals or notifications.
When in doubt, prefer a single process first and extract subprocesses only when complexity demands it.

RE: Process Model

Mathieu Drouin — Mon, 27 Apr 2026 21:34:00 GMT

Mike/Varun have some excellent points. Here is an additional resource with some information you might find useful:

community.appian.com/.../how-to-create-memory-efficient-models

RE: Process Model

Mike Schmitt — Mon, 27 Apr 2026 20:50:13 GMT

Much of what Varun already wrote above is pretty on-point. I would offer my simpler take: it's not "either-or", and there is no "strictly right answer". Often what happens is a process evolves over time and you realize that certain sections represent functionality you'd rather have reusable across different processes (without having to rebuild it over and over again, and without the risk that it drifts apart in functionality), so you encapsulate those pieces into a subprocess. I do wish the process of accomplishing this were a little bit faster or more painless, but I don't know what's feasible.

RE: unable to create multiple exception flows in User Input Task in Process Model

Shubham Aware — Mon, 27 Apr 2026 11:51:48 GMT

You cannot create multiple exception flows from a single User Input Task it strictly allows only one exception flow per activity node.
Any events configured within the task (Timer, Message, or Rule) will all trigger that same single path.
Workaround you could try ->
Wrap your UIT in a Sub-process. In the parent process, place a Timer event and a Receive Message event in parallel to that sub-process. Configure these events to cancel the sub-process node when they trigger, allowing each to lead into its own unique flow.

unable to create multiple exception flows in User Input Task in Process Model

ravitejam — Sat, 25 Apr 2026 11:39:42 GMT

I want o create two different exception paths for user input task one with timer and another one with recieve message each will go to different flow. I am using appian version 26.3 i am unable to do it as i am getting only one flow out of user input task exception. Can any one help me regarding it.

If i use recieve message exception and timer symbol is changing to Home icon

If i use only timer

If i Use only message it is showing at the same place and i am unable to move the symbols as well

Why does a Record Action start a process successfully but not pass the record data (identifier and record) to parameterized process variables?

mohitr083133 — Fri, 24 Apr 2026 17:56:17 GMT

A Record Action is configured to start a process model, and the process launches successfully. However, the parameterized process variables (record type and identifier) remain null or default values during runtime. As a result, the interface cannot display the expected record data.

RE: Why does a Record Action start a process successfully but not pass the record data (identifier and record) to parameterized process variables?

Shubham Aware — Mon, 27 Apr 2026 06:58:55 GMT

Ensure your input parameter names are exactly record and identifier (case-sensitive), with the correct data types matching your Record Type.
Hope Process variables set up as Input Parameters in the process model.

RE: Why does a Record Action start a process successfully but not pass the record data (identifier and record) to parameterized process variables?

Harsha Sharma — Mon, 27 Apr 2026 06:37:17 GMT

Check in the Record that you are passing proper record action context against the parameterized process variables to the related action.

RE: Why does a Record Action start a process successfully but not pass the record data (identifier and record) to parameterized process variables?

VarunTejaGurrapu — Mon, 27 Apr 2026 04:51:19 GMT

Hi mohitr083133 ,

From my understanding, The Record Action is successfully initiating the process model, but the parameterized process variables (record type and identifier) are not being populated correctly, causing the interface to receive null or default values instead of the expected record data.

I suggest you to check for certain things:

1. Parameter Mapping Configuration

- Verify that the Record Action's parameter mappings are correctly configured

- Ensure the source values (record type and identifier from the record action context) are explicitly mapped to the process variables

- Confirm the variable names match exactly between the Record Action configuration and the process model definition.

2. Process Variable Definition

- Check that process variables are properly declared in the process model with correct data types

- Verify initial values are not overriding the passed parameters

- Ensure variables are defined as input parameters, not local-only variables

Solution Steps:

- Reconfigure the Record Action to explicitly map context values to process variables

- Test with hardcoded values first to check whether the issue is in mapping or data retrieval

- Validate the interface rule is querying the correct process variables with proper syntax

RE: WEB API process model restart and error handling

priyadarshinig465 — Sat, 25 Apr 2026 19:24:07 GMT

Appian does not directly provide an option to restart a failed process instance from the exact broken node. The better approach is to design exception handling with retry logic or create a separate recovery process that uses the Process ID to re-run the failed asynchronous subprocess or integration. In short, this is usually managed through process design rather than manual restart from the failed step.