DB Tasks Vs Traditional UIT Design

RE: DB Tasks Vs Traditional UIT Design

Jacob Benjamin — Mon, 06 Jul 2026 17:23:21 GMT

I'm going to resurrect this as I see most folks advocating for the OOTB task approach - is this still the favored approach? I've long held that DB tasks are the way to go - especially in regards to scalability and control over the platform. The OOTB tasks may be faster in the short run, but long-term you are going to be paying for it if you find that you do need to transition over the DB tasks. Also - general Appian best practices is to limit the use of long-running processes, which the OOTB task approach can encourage.

All this said because I'm looking for a recipe on how to implement DB tasks easily...

RE: DB Tasks Vs Traditional UIT Design

mrsoul — Thu, 20 Jul 2023 12:25:20 GMT

Basically, Konduru is saying you will maintain a list of tasks in the database without any Appian processes running. There is a report which shows this list of work to the "assignee" that is listed in the database. From this report, they can initiate a task on that item at any time, and that will lead to the creation of a short lived Appian instance. Therefore, the "task" (and the associated process) is only activated on an ad-hoc basis rather than being activated all the time.

When items are created, they are assigned Appian Tasks, which utilize Appian memory until completed and the entire process is complete and closed, making this different than assigning Appian Tasks when items are created.

RE: DB Tasks Vs Traditional UIT Design

Chris — Wed, 19 Jul 2023 17:35:03 GMT

I believe what Konduru is saying is, in that setup you will maintain a list of work to do in the database, with no Appian process or task active. Then you have a report showing this list of work to the "assignee" listed in the DB, from this report they can choose to initiate a task on that item at any time, which will then create a short lived Appian instance. So, the "task" (and associated process) is only activated ad-hoc instead of always.

This would be different than assigning an Appian Task for each item when it is created, which utilizes Appian memory until completed and the process ends.

RE: DB Tasks Vs Traditional UIT Design

thevarunbawa — Wed, 19 Jul 2023 07:21:03 GMT

Mike Schmitt

That's a hurried mistake. I have edited my comment. My apologies for any kind of misleads.

RE: DB Tasks Vs Traditional UIT Design

Mike Schmitt — Mon, 17 Jul 2023 14:17:55 GMT

edit: redacted mistake - thanks for explaining 🙂

Was this supposed to be something meaningful to anyone?

RE: DB Tasks Vs Traditional UIT Design

thevarunbawa — Mon, 17 Jul 2023 10:21:17 GMT

That's a mistake. I was supposed to post a community discussion thread link related to the question here but in hurry ended up posting the teams link by mistake. My apologies.

Originally the comment was to understand the point made by Konduru Chaitanya in the below discussion. Can someone please clarify?

community.appian.com/.../how-to-store-task-report-data-into-db

RE: DB Tasks Vs Traditional UIT Design

Ignacio Morán — Mon, 17 Jul 2023 07:41:02 GMT

I also recommend to use OOTB features, just consider the next thing as I have already seen some performance issues using the OOTB:

When creating a report make sure you do not apply any logic in the columns, just take directly the process variable, if any logic is needed, do it in the PM and expose it to the report. Applying logic to in the columns could generate bad performance if a high number of rows are queried with a!queryProcessAnalytics()

RE: DB Tasks Vs Traditional UIT Design

Mathieu Drouin — Sun, 16 Jul 2023 11:58:11 GMT

I don't recommend this approach as well. OOTB features are meant to save you time. If you end up reimplementing those features, I think you would need a pretty good reason.

RE: DB Tasks Vs Traditional UIT Design

Stefan Helzle — Sun, 16 Jul 2023 10:42:48 GMT

I strongly suggest to stay with Appian OOTB as much as possible. Use processes and UITs. This is what Appian is made for. And this is not a "traditional" vs "somethingElse". IMHO, this is more about people trying to force Appian into a use case it is not made for.

And yes, there are use cases which cannot be implemented in the "traditional" way. But they are very rare.