Once a user accepts a task, is there a way to update the status of a CDT in the database?

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

  • 0
    Certified Lead Developer

    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?

  • 0
    Certified Lead Developer
    in reply to erickp0001

    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.

  • 0
    Certified Lead Developer
    in reply to erickp0001
    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.

    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.

    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.

  • Hello,

    I think it might be a good idea to explain further why you need to do this or to rethink the approach.

    In terms of reporting, I don't see an explicit need of writing on a DB the status is accepted but not completed doing so. Why? Because you can already have a Database where you can check this. There is an status "Accepted" and "Assigned" when someone selects a task and to read it, all you need to do is to create a task report and an expression rule that uses a!queryProcessAnalytics.

    With that expression rule that calls the processAnalytics, you can already make a report or set it up on an interface.

    I don't see much reason to notify user just in the instant someone has accepted the task (at that moment, that user is probably working on it), but rather if after a time certain time, in which the user did not completed the accepted task. In that scenario, you could do like Mike suggests, or even add it more logic (check time stamp when the task was accepted and compare with now())

    Good luck!

    Best,

    Manuel