Human dependent long running Workflows

Not sure if this has been discussed before, I did a search in the forums and so far haven’t found exactly what I was looking for.
But I am trying to find best practices for creating Human dependent long running workflows and specifically How I would represent things like task/approval queues, where users see a task in their queue, they select it, assign it to themselves or someone else, They do what they need to do, add data to the request etc, and then submit and update the workflow at which point it gets to the next step.
Sorry for the question, temporal and other Workflow orchestrators are new to me so I am trying to get down the patterns and best practices.

So I guess I should explain what I think I understand so far. So in Temporal I would define what steps would happen when in a Workflow. In that workflow I would define various activities for non-deterministic executions like API calls, IO operations (writing files etc).

I would query the state of the workflow using queries, I would update the state of the workflow using Signals.

I am trying to map that to what I understand queues would be. Imagine if I had a process where I was an approver of some sort of request. And when I approved I sent it up to my boss to get his approval.
And I could have a stack of approvals in my quote un quote queue?

I think in the Ecommerce application example that would be represented by multiple instances of the workflow all waiting on input at a certain step correct? Or would that be represented by tasks in the task queue?

Again sorry for the question still wrapping my head around these concepts. Thanks again!

I think your requirements are similar to those asked in this forum question.
Yes your thinking is correct as in having an activity that updates an external system responsible for interacting with the human actor, and then use signals to notify the workflow of the completion of the human decision.

Note that with temporal you can write your code to wait for multiple signals, in the case where you might require decisions from multiple human actors in order to move forward with the next activity. This post has some code samples that show off how to do it completely async.

You can think of task queues as “endpoints” on the temporal server. Your workers listen to those endpoints waiting to pick up tasks and use the task info to process /continue processing your workflow executions.

Let us know if you have any further questions / concerns.

1 Like

Adding to @tihomir answer. You can store the list of task assigned to a human in an external system. Another option is to have a workflow instance per approver. And keep the list of assigned tasks in those approver workflows.

1 Like

Thanks @tihomir and @maxim. Im putting together a little UI with a little workflow beneath it as a proof of concept to see if this solution is right for the problem I am trying to solve. And so far its looking that way. I appreciate you answering my questions on best practices.

I am probably being a little bit dense with this particular topic so I apologize.
But the concept of having a workflow instance per approver is just not something I have thought of.

What If there are multiple Approval Steps in this process for example, let’s say there are seven approval steps. When the requestor creates a request, Would There need to be an instance of a workflow for each approval step? Or would there be one instance of the workflow that arrives at 7 different states (as defined in the workflow definition).

So, Imagine I wrap temporal in an API, on top of it I have a UI, and in the UI I create a UI queue (Just html) representing all the Approval requests at that step that that user has access to. Are you saying that each of those instances would be an instance of a temporal workflow?

And When that user logs on I would have an API to fetch all the workflow instances assigned to that user? The same for each User at each step? When a request is rejected at certain steps in the approval process and it must go back to a previous step, how would that be represented?

Would this be more simply represented using a state-machine? If not how would that particular example best be modeled. Is there a sample that comes close to matching that use case?

This is really intersting! :slight_smile:

in some of my usecases i have 2 or 3 approvals and some of them are auto approved (green channel ) based on use cases.

i typically use signals and await for getting these done (typically the main workflow method is a while true loop)

So your main workflow is a while true loop, you have a workflow for each approval step? I don’t know why but I am having a hard time envisioning that?

I would recommend using OO techniques to model each human interaction as a class. Then you can have many of them in parallel or in a sequence through a nice interface.

Ya main workflow is while loop. The work flow has a state which gets modified through signals. Inside the while loop I have a switch case which does various activity and gets back to worklow.await(onSomeSignal)
E.g main is a subscription management workflow … once a customer subscribes to a product a workflow get created and await on expiry date or some signal (unsubcribe etc).

The cleanup/unsubcription etc needs manual approval. E.g if it’s it’s trial account the subscriptions are terminated after trial period. If it’s paid subscriptions ops/sales get an alert, when some one approves the clean up it get processed…

So essentially after approval the work flow terminates… if cleanup is rejected or subscription end date extended… the workflow goes back to subscribed state and awaits further signals… that’s done in the while loop.

Kudos to the team on this article:

Very thorough and what I was looking forward to help me set up a little POC.

4 Likes