Best Practices - Recent Threads

RE: State in appian

elvisb958752 — Wed, 13 May 2026 16:17:00 GMT

I was able to come up with a solution. Thank you for your response anyway!

State in appian

elvisb958752 — Tue, 05 May 2026 12:13:01 GMT

Is there any way in Appian to capture the previous state?
I have a form with a couple of dop downs where the user selects different assignees for different tasks
I want to able to send an email only to the changed users.
Is there any way to compare old user values with new ones to see if changes happen?

RE: State in appian

elvisb958752 — Wed, 13 May 2026 16:16:19 GMT

ur answer is the same as Stefan, u need to understand that once u save them locally there is no difference anymore, ur comparing the same value, values never get updated locally, they get updated once u write them to database. I was able to find a solution, but thank u for ur answer.

RE: Appian Cloud Service

danielled676203 — Wed, 13 May 2026 12:50:08 GMT

Interesting article, I recommend reading it - www.abtosoftware.com/.../robotic-process-automation-services

Appian Cloud Service

joep45 — Mon, 11 Jul 2016 21:59:37 GMT

For those running Appian in the cloud is it considered SaaS or PaaS?

pessimistic locking

MM — Thu, 23 Apr 2026 12:07:30 GMT

I am considering implementing pessimistic locking in Appian.
However, I have heard that pessimistic locking can potentially degrade performance because it restricts concurrency.

In practice, how much impact does pessimistic locking typically have on performance?
Also, from a best practice perspective in Appian, what kind of design or implementation approaches should be considered?

Specifically, I would appreciate guidance on topics such as:

In which scenarios does pessimistic locking have a significant performance impact?
When should pessimistic locking be used, and when should it be avoided?
If pessimistic locking is required, are there any design techniques or best practices to minimize its performance impact?

RE: pessimistic locking

Mike Schmitt — Tue, 12 May 2026 12:24:17 GMT

[quote userid="335211" url="~/discussions/f/best-practices/40366/pessimistic-locking/154584"]Appian does not provide a direct equivalent of `SELECT FOR UPDATE`, which means multiple users may end up selecting the same “next” voucher concurrently.[/quote]

If you implement a process that quickly (in successive nodes) does this check-then-write, structured like I described in my prior comment, then users will not be able to do this. Not accidentally, and not even if they're testing to try to break the system you have set up.

[quote userid="335211" url="~/discussions/f/best-practices/40366/pessimistic-locking/154584"]

whether pessimistic locking on such an object could become a bottleneck or cause noticeable performance degradation.

[/quote]

If your system can already handle several thousand users working concurrently, a system like the one I described should make little to no performance difference.

[quote userid="335211" url="~/discussions/f/best-practices/40366/pessimistic-locking/154584"]Any insights would be greatly appreciated[/quote]

Just design something and test it. Keep the lead-up sequence tight, and pay attention to the ordering of the nodes so as to handle the different use cases (e.g. when two users both click the same task within a few seconds of each other from their task lists).

RE: pessimistic locking

MM — Tue, 12 May 2026 11:07:28 GMT

Sorry for the delayed follow-up, and thank you very much for your responses.

Thank you for the detailed explanations so far — they are very helpful.

Let me add more context about my actual use case, as it seems quite relevant to the DB-backed task example you mentioned.

In our business scenario, multiple users work together to review and correct already-registered voucher (transaction) records in Appian.
The workflow is not task-based; instead, users pick records from a shared pool and work on them one by one.

The intended behavior is:
- When a user starts working on a voucher, its status is updated to “In Progress”.
- The voucher that was previously being handled by the user is set back to “Accepted” (or a completed state).
- We need to ensure that the same voucher cannot be picked by multiple users at the same time.

In a traditional database design, this would typically be handled using something like `SELECT FOR UPDATE` to atomically claim the next voucher.
However, as far as I understand, Appian does not provide a direct equivalent of `SELECT FOR UPDATE`, which means multiple users may end up selecting the same “next” voucher concurrently.

Because of this limitation, we are considering introducing a dedicated object (or table) to manage voucher assignment and status, and using pessimistic locking to ensure exclusive ownership while a voucher is being edited.

My concern is scale: in peak periods, several thousand users may perform this operation at roughly the same time.
That raises the question of whether pessimistic locking on such an object could become a bottleneck or cause noticeable performance degradation.

Given this context, I would appreciate guidance on:
- Whether this type of “first-claim-wins” record assignment is a reasonable use case for pessimistic locking in Appian
- Any design patterns or architectural techniques to minimize contention and performance impact (for example, batching, sharding, or alternative locking approaches)
- Or whether there is a more Appian-native pattern that would be preferable for this kind of scenario

Any insights would be greatly appreciated.

RE: Safely removing unused columns identified via dependency checks in Appian

VarunTejaGurrapu — Wed, 06 May 2026 06:52:24 GMT

Hi udhay kumar ,

I strongly follow this approach, its just my opinion as per best practice, you can also follow this:

Firstly, Check the dependencies in :

Process Models, Integrations, Database-level dependencies (SP,views,Triggers), Running Processes.

Best way to delete:

Step 1: Soft deprecate (recommended)

Stop using column in Appian
Remove from CDT + record type
Keep column in DB

Step 2: Deploy & monitor

Watch logs
Check process failures
Validate integrations

Step 3: Drop column in DB (if not dropped, you can use those fields in future, if needed)

ALTER TABLE table_name DROP COLUMN column_name;

Safely removing unused columns identified via dependency checks in Appian

udhay kumar — Tue, 05 May 2026 16:34:59 GMT

Hello all,

I have come across certain columns of different tables which are not being used in anyway. To validate this, I have done the following :

Check for CDT dependencies Check for record type dependencies Search for usage of the field/column globally in the application

Based on the above, it appears that these fields are not being referenced by anything.

But prior to deleting the columns, I wanted to get your feedback regarding the following:

Does the above process ensure that the columns can be deleted without causing any issues ? Is there anything else that needs to be checked prior to deleting such columns (Process Models, integration etc.) ? What is the best way to delete such columns in Appian ? Am I supposed to deprecate these columns prior to their deletion ?

Thanks

RE: Safely removing unused columns identified via dependency checks in Appian

ayanchoudhury — Wed, 06 May 2026 06:47:59 GMT

I think if you are having a record type then then the dependency will be sugested by appian when you are removing he column, if so you are using CDT the check the dependent artifacts and might need to remove those dependencied if they breaks.

RE: Safely removing unused columns identified via dependency checks in Appian

pradeepkumawat — Wed, 06 May 2026 06:15:47 GMT

Open Record, navigate to the Data Model, and click the delete icon next to the column you want to remove. Appian will automatically display all dependencies for that column. Review them carefully and remove or update the dependencies wherever the column is being used.

RE: State in appian

VarunTejaGurrapu — Wed, 06 May 2026 05:33:53 GMT

Hi elvisb958752 ,

Its basically a field level audit, but we need to store them in a local variables first and compare them, when clicked on Submit, just store the difference of the data from local variables into rule input and pass them into PM, that will be the best approach, stefan's answer states the same!

RE: Safely removing unused columns identified via dependency checks in Appian

GauravSingh — Tue, 05 May 2026 19:35:55 GMT

You’re already doing the right kind of due diligence—but I wouldn’t call it “safe enough to delete” just yet. In Appian, unused-looking columns can still bite you later because usage isn’t always obvious or directly referenced.

Appian has indirect usage patterns that won’t show up clearly in these checks: like Process variables (PV mappings),Script tasks / expressions, Smart services (Write to Data Store, integrations).

if Appian doesn’t use the field internally, External systems might expect it, APIs might still send/receive it so you can check the following objects: Integration objects, Web APIs, Connected systems

Sometimes fields are dynamically referenced (fv!item[fieldName])

Database-level dependencies: Check in DB Views using the column, Stored procedures,Triggers

So on a high note instead of deleting it Rename column from fieldname to fieldname_DEPRECATED and verify if its working or breaking the logic

RE: Safely removing unused columns identified via dependency checks in Appian

Stefan Helzle — Tue, 05 May 2026 19:09:00 GMT

I think your approach is valid. Just make sure there is no dependency. To validate this, you could rename the columns and check whether the application keeps working. Then, delete them after validation.

RE: State in appian

Stefan Helzle — Tue, 05 May 2026 19:06:16 GMT

Do you want to explain your current implementation in more detail? I am sure we can find a way to get this working.

RE: State in appian

elvisb958752 — Tue, 05 May 2026 14:47:22 GMT

I cannot pass local variables to the process model. If i use the difference function the process model is gonna read them as null.

RE: State in appian

Stefan Helzle — Tue, 05 May 2026 12:19:46 GMT

The difference function allows you to compare two lists. Store the old selection to a local and compare it to the new on submit.

RE: pessimistic locking

Mathieu Drouin — Mon, 27 Apr 2026 21:28:32 GMT

This article provides a good roundup of the trade offs as well as a App Market implementation

https://community.appian.com/success/w/article/3213/data-locking-strategies

RE: pessimistic locking

Mike Schmitt — Thu, 23 Apr 2026 13:45:48 GMT

This is entirely context dependent. What are you hoping to implement this on?

For instance, I've implemented this before to do database-backed faux-group-tasks - as in, when a user sees a "task list" that's really queried from a DB where you control who sees the "task names" via whatever databse-backed controls you devise, and clicking the link (instead of actually opening a running task) launches a process that then freshly invokes the actual task. After clicking, a quick DB query establishes that nobody else has opened it yet, and if not, a quick write is made to soft-assign it to that user. If someone else had opened it, the user is routed to a "fallback" task telling them someone has opened it already.

As long as this is well thought out, and conscientiously designed, the "performance impact" is essentially nothing. It works so quickly that users wouldn't notice any difference even under stress testing conditions, IIRC.

But if your use case is something far removed from this (which I have no way of knowing since you didn't really specify), then I can't really speak to it.

RE: pessimistic locking

Stefan Helzle — Thu, 23 Apr 2026 12:12:51 GMT

Well, if you need locking, the impact is a consequence of that decision.

My first question would be more like, why do you think you would need locking.

RE: Nested CDT takes too long to query data

Harsha Sharma — Tue, 14 Apr 2026 10:13:12 GMT

Appian doesnt recommend to use Nested CDTs in general. So better to normalise the cdts using foreign keys would be the best approach, if feasible. Or even move to record type/ data fabric!

For time out, find the cause of the time out in query. E.g. try querying 1,10 or 100 rows as per need to find the root of the timeout issue.

Another suggestion is if you are querying to show data in a grid, which is why you might need to query multiple rows - query just the main record data (except nested cdts) and show them in grid. The relative nested data can be queried and shown in separate UI component for each row - thus nested data will be queried one for each row rather than multiple at once.

Can discuss further for each of the above approaches, yet hope these general suggestions help.

Nested CDT takes too long to query data

Linh — Tue, 14 Apr 2026 09:10:42 GMT

Hi everyone,

I'm having a multi layer nested CDT (Nested CDT that is a column in another nested CDT column of the main CDT that uses as data type) which is taking too long to query data and sometimes causes time out error. I would love to have some suggestion to optimise/ replace it with something else if possible.

Thank you

RE: Nested CDT takes too long to query data

Shubham Aware — Tue, 14 Apr 2026 10:09:56 GMT

Deeper nesting can create an N+1 query problem and slow queries or timeouts.
Create a DB view with the required JOINs and map it to a single flat CDT. Then query that view with one a!queryEntity() call, using paging and only the fields you need.
For longer-term maintainability, consider Record Types with Relationships(Replace deep nested CDTs with flat related CDTs)

RE: Nested CDT takes too long to query data

Stefan Helzle — Tue, 14 Apr 2026 09:39:15 GMT

Well, you will have to analyze why it takes so much time. Try to fetch only the data you need.