Once a user accepts a task, is there a way to update the status of a CDT in the database?
In my attempt to implement this, I created a process and configured the start event to receive a message (the setup tab is as shown below). In the Data tab, I added 'msg!properties'.'CDTNAME' as the Value and storing that in the process variable CDTNAME. Here, CDTNAME contains a status field which we want to update to Accepted and then write into the database. In the process that contains the user input task I was wondering if there is a way to configure an escalation event to send a message to this process once the task is accepted?
Are there any other ways to do this?
Discussion posts and replies are publicly visible
I don't think there's a way to do this instantly. However if it doesn't need to be instant, exactly, then you could set up a looping timer that repeatedly checks the "owner" value for the task (as seen from a task report), which only becomes set when a user accepts the task - and when it finds a value, then execute whatever subsequent steps you were needing.
Is that the approach others are taking to be able to build a centralized report containing "Active task data" together with application data (stored in the database)? For example, we have different statuses: Submitted, Under Review, Completed, Follow Up and Cancelled. The only status that I can't report on from the database is Under Review because it lives in the process report. Under Review means a user "Accepted" the task. I want to build a report where user can filter by all statuses, including under review, from the database. Thoughts?
I'm not sure if what you're describing is that common of a use case, but this is the only way I know of to do what you describe. I think the more common approach in the age of Sites is to have purely DB-driven tasks as opposed to tasks in running process instances that just sit around until a user accepts them.
So you are saying that it is uncommon for people to have to report on tasks that have not yet been taken by a user? That seems to me like an important case from productivity perspective. With a purely DB-driven task approach, how would you accomplish this? Seems to me like it would come handy if Appian gives us the ability to start a process when user clicks on the out-of-the-box Accept button of a task.
erickp0001 said:So you are saying that it is uncommon for people to have to report on tasks that have not yet been taken by a user?
I think it might be more accurate to say that it's not very common (any more, at least) for there to be active tasks that aren't assigned directly to a user, and therefore accepted implicitly. In legacy cases, I suppose it was sufficient for Portal Reports to be used to report on such cases, which is easy since the value of tp!owner can be used to tell whether a task has been accepted.
erickp0001 said:Seems to me like it would come handy if Appian gives us the ability to
I agree that it's annoying, but given that Appian doesn't give us the ability to trigger processes or smart services from basically any out-of-box UI functionality (accept task, reassign task, update of user profile properties, etc, etc, etc), this shouldn't come as much of a surprise to anyone.
erickp0001 said: With a purely DB-driven task approach, how would you accomplish this?
Most likely by setting up task acceptance in such a way that the "tasks" are merely entries in a DB and when clicked, launch a fresh process instance, and "acceptance" is driven by functionality I put into the SAIL form manually, instead of utilizing the untouchable out-of-box "accept task" functionality. In this way, row locking / task acceptance / etc can all be fine-tuned to your own needs and updated live, by your own process / SAIL forms.