Workflow replacement - Flows or Playbooks

[Khanna Ji]

Hello Everyone,

I'm facing a decision regarding migrating our workflow to either Flow Designer or Playbooks. I'm uncertain about the best course of action. We have a key workflow that is crucial for our catalog items, as it retrieves data from a custom table to manage approvals and tasks, and it's utilized for 90% of our catalog items.

Should we focus on converting this workflow into flows, or should we opt for playbooks, either creating one for each catalog item or a single, common playbook (if feasible)?

I'd love to hear about your experiences or approaches in similar situations.

[Shaqeel · Accepted solution]

Hi @Khanna Ji 

In your case, since the workflow drives 90% of catalogn items (approvals, tasks, custom tables), this is an ideal candidate for Flow designer.

Use Playbooks only if you need agent- facing guided experience in workspace.

Regards

Shaqeel

[Khanna Ji]

Thank you @Shaqeel  but why do you think Playbook is not a good idea?

[Dr Atul G- LNG]

Hi @Khanna Ji 

My above answer can be helpful for this.

Main points:

• Playbook is mainly instruction-based:

  1. Do this

  2. Then this

  3. Then this

• Flow is trigger-based and works on conditions. Based on the next action from the user, it moves to the next state or activity.

Recommendation:

• Use Flows when the process is conditional and automated.

• Use Playbooks mainly when an agent needs to make decisions or take actions based on system-provided guidance.

In catalog we have standard way of working no divation. 

[Dr Atul G- LNG]

Hi @Khanna Ji 

It is based on use case:

When to use flows

Flows, subflows, and actions are the basic building blocks of process automation. Flows run when their trigger conditions are met, and each flow in turn runs a sequence of actions, flow logic, and subflows. The actions, flow logic, and subflows within a flow are what create and update data.

A flow is a good fit for process automations that met these criteria.

Expect few to no manual user interactions

As long as a flow has the input data it needs, it can run to completion without any user interaction. Some flow logic and actions require users to make record changes, but a flow can automatically pause until its wait conditions are met. Process automations that depend on user interactions such as reading a knowledge base article, going through a checklist, and gathering feedback are harder to manage with flows. Flows don't directly provide any UI elements for users to interact with. Flows depend on users knowing how to find an existing UI and making any needed changes. For example, a record-based flow depends on a user making a change in a specific record such as a case or an incident.

Expect to run at high volumes

An instance can run hundreds to thousands of flows per second. With flow reporting being disabled by default, an instance can run a high volume of flows before it sees any performance impact. If you expect to run a process automation at high volumes, a flow is a good fit over a playbook because it requires less overhead and system resources.

Expect to run few to no subflows

The more subflows a flow calls, the more difficult it becomes to manage from the flows interface. While you can use conditional flow logic or a decision table to choose a subflow to run, playbooks offer a better user experience for running a sequence of subflows.

When to use playbooks

Playbooks are built on activities, which use prebuilt flows, subflows, and actions as their building blocks.

A playbook is a good fit for process automations that met these criteria.

Expect several manual user interactions

Playbooks provide UI elements for users to interact with. The playbook experience guides users to make any changes required to advance the playbook.

Expect to run at low volumes

Playbooks require more system resources to run because they generate UI elements and store more execution details.

Expect to run many subflows

Playbooks offer a better user experience for running a sequence of subflows.