Redirect user to a task form using Appian WebAPI

Hi team,

Use Case:
User wants to access specific Appian task form from the external system. The task is not readily available. But, based on the request, the process would get triggered and a task is generated.

So, the ask here is to create a web API which initiates the process which generates the task, get the task ID, and constructs the task form link, and lastly redirects the user to the link that is just generated.

Is this possible using Appian's Web API?

Thanks,
Akshar

  Discussion posts and replies are publicly visible

Parents
  • I realize it's less likely, but if the user is on mobile, they can get a push notification that they can then tap on to take them to the task.

    And, now that I think about it, the experience wouldn't necessarily be all that different on desktop if they have desktop email notifications (which many people do). So, once the task is created, the user would get an email notification in the corner of their screen with a link to the task. 

    I know that's not exactly what you had in mind, but from a functional standpoint, it might not be that far off. 

    If you're having trouble figuring out how to interact with the process via a web api, you can also publish a process as a web service in order to invoke it from an external system. https://docs.appian.com/suite/help/19.2/Publishing_Process_Models_as_Web_Services.html   

    Another potential approach to consider, depending on how much flexibility you have with the external system, would be to make two requests, along with some sort of identifier. So, you might do something like:
    1) Start process (either via a POST request or web service call), passing your identifier as a parameter (for example, "id=3")
    2) In the process, associate the identifier you passed in with the task you end up creating.
    2a) (depending on how things go for you in testing) *brief pause/sleep to let the task get generated*
    3) Make a GET request to get the task link, using the identifier. (If you want, you can even have the request do a redirect to that link, as Josh suggested, with maybe a fallback url, like the tasks tab, in case you do have instances where the task hasn't yet been generated when the GET request is made.)

    It would be important to keep the different steps very lightweight (for example, if you want to store the identifier-to-task associations in a database, maybe have a table with only those two columns, and clean up the table entries when tasks are completed. Or, as another example, make the task a very early node in the process--if the task has 15 nodes in front of it that have to get completed first, you're more likely to end up with timing issues). But I could honestly see this still yielding a pretty smooth experience for the end user, even if you have to split up the steps behind the scenes. 

Reply
  • I realize it's less likely, but if the user is on mobile, they can get a push notification that they can then tap on to take them to the task.

    And, now that I think about it, the experience wouldn't necessarily be all that different on desktop if they have desktop email notifications (which many people do). So, once the task is created, the user would get an email notification in the corner of their screen with a link to the task. 

    I know that's not exactly what you had in mind, but from a functional standpoint, it might not be that far off. 

    If you're having trouble figuring out how to interact with the process via a web api, you can also publish a process as a web service in order to invoke it from an external system. https://docs.appian.com/suite/help/19.2/Publishing_Process_Models_as_Web_Services.html   

    Another potential approach to consider, depending on how much flexibility you have with the external system, would be to make two requests, along with some sort of identifier. So, you might do something like:
    1) Start process (either via a POST request or web service call), passing your identifier as a parameter (for example, "id=3")
    2) In the process, associate the identifier you passed in with the task you end up creating.
    2a) (depending on how things go for you in testing) *brief pause/sleep to let the task get generated*
    3) Make a GET request to get the task link, using the identifier. (If you want, you can even have the request do a redirect to that link, as Josh suggested, with maybe a fallback url, like the tasks tab, in case you do have instances where the task hasn't yet been generated when the GET request is made.)

    It would be important to keep the different steps very lightweight (for example, if you want to store the identifier-to-task associations in a database, maybe have a table with only those two columns, and clean up the table entries when tasks are completed. Or, as another example, make the task a very early node in the process--if the task has 15 nodes in front of it that have to get completed first, you're more likely to end up with timing issues). But I could honestly see this still yielding a pretty smooth experience for the end user, even if you have to split up the steps behind the scenes. 

Children