Approval Step

[nileshtrivedi]

Business Processes are real-world workflows spanning multiple actors. They are like programs, running on multiple processors which might be individual humans, or groups of people or computer systems. People can be outside the org (eg: customers, vendors).

Here is an example workflow where people and systems collaborate to achieve something:

In this frame of thinking, a company is like an operating system for business processes.

Because these workflows can have branches, loops, events etc, they are very much like programming languages. There exist standards like BPMN, SMMN, DMN etc and various software like jBPM, Camunda, Flowable to model and execute these.

It would be really great to be able to create workflows like these in ActivePieces because so much of the required work has already been done.

Essentially, the system should support new worker types which represent people/groups of people identified by a communication channel like email/SMS/API call etc and to which tasks can be delegated. These workers are slow, so the system should not spend resources while waiting for an event. For eg: "A ticket should be escalated to the manager if it is not solved in 7 days".

This will make it possible to embed ActivePieces based automations right inside actual business processes while making use of ActivePieces's existing infra that supports branching/looping/delay and a canvas-based workflow editor.

[nileshtrivedi]

Some useful resources:

• http://www.workflowpatterns.com/patterns/control/
• http://www.workflowpatterns.com/patterns/resource/
• https://mainthing.ru/item/813/
• https://raw.githubusercontent.com/bokmann/stonepath/master/docs/stonepath.pdf

[abuaboud]

Hi @nileshtrivedi, I am considering a new feature for the piece framework that could be useful.

To elaborate, suppose you wish to proceed with a task based on approval, within the framework, you can incorporate a function inside framework like context.waitForApproval(). This will generate two URLs - one for continuing the flow and the other for canceling it. These links can be used in emails.

For instance, you can create an Approval Email Piece that sends an email with two buttons. If the user selects the cancel URL, the flow will stop. If they select the continue option, the flow will proceed.

I think once this is completed, we can model such flows.

@nileshtrivedi What do you think?

[nileshtrivedi]

@abuaboud This is a good start but a YES/NO, APPROVE/REJECT flow fundamentally, is about collecting a single bit of data from a human actor. IMHO, a more general and powerful flow would be sending an incomplete JSON object - to be rendered as an HTML form - and receiving a completed one from the person.

[abuaboud]

@nileshtrivedi this is decent, maybe we could extend it for something like this

context.waitForAction(['submit', 'cancel']) It will generate an URL for each action and you can use the response from their http body, in the piece you could construct the form and send in the email.

[nileshtrivedi]

Yes, this would be perfect. There should not be any special behavior for the action names. They're just identifiers for action/URL. The piece has all the custom logic.

The rest of the flow after this piece should proceed only when any one of the action forms are submitted. So, any piece that uses context.waitForAction behaves like "indefinite delay till a response is received". When one action is submitted, all these URLs should be deactivated.

[LinusInnovator]

I think this would be great as well. I’m thinking it would also be great with a “standard” for showing where the user are in such a process, like a “baseplate” way to show a multistep process.

[abuaboud]

Done and will be released in 0.5.0

[github-actions[bot]]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see. If this issue is continuing with the lastest stable version of Activepieces, please open a new issue that references this one.