The Playbooks catalog lists every Playbook in your account. From here you can search, filter, sort, and open any Playbook to edit it. The catalog loads one page of Playbooks at a time, so it stays fast even in accounts with hundreds of Playbooks.

To open the catalog, go to your Settings (⚙️), and under Operations select Playbooks.

Searching and filtering

Search, filtering, and sorting are all applied across your entire catalog, not just the page currently in view.

Exporting to CSV

When you export the catalog to CSV, the export reflects your active search, filters, and sort order, so you get exactly the set of Playbooks you're currently viewing.

This is a great way to troubleshoot who actively matches your playbook today! If they are not in this list, they do not match the playbook, so looking at what they are missing is a great first step.

Playbooks include a built-in test feature that lets you preview how a specific account would move through the playbook without triggering any actions. No traits are updated, no conversations are sent, and no emails are generated — the test is entirely safe to run before your playbook goes live.

How To access the test feature:

Important: The record you test with must match the playbook's trigger rules. If it doesn't, the test will indicate that the record doesn't qualify.

When the playbook includes branches or wait actions, the test path is determined based on the current state of the record. For example, if a branch checks whether a customer replied to an email message, and that message hasn't been sent yet, the test assumes no reply has occurred.

You can easily view all objects, like Tasks or Conversations, that were created by a particular Playbook action. This is great for confirming that all of your conversations were created for an email blast, or viewing all the indicators the Playbook has applied to your customer records.

For any action in your Playbook (e.g., Create Task, Start Conversation, Create Goal), you can now:

Another great way to troubleshoot who has gone through a playbook, who is currently running through one, when they ran, and when they stopped matching the playbook trigger rules!

When viewing a Playbook without selecting a specific run, each action shows the number of runs completed and the completion percentage, along with statistics specific to that action. When selecting a specific run, each node updates to show exactly what happened in that run.

Conversation actions will show metrics around Active and Pending messages as well as any Send Errors, with direct links to filtered table views.

Wait actions will display insights for any completed runs as well as those currently holding in the wait period.

Branched playbooks will show run metrics, including the percentage that ran down each branch.

You can instantly spot drop-offs, bottlenecks, or error patterns. If an action affected multiple targets, you'll see a summary and can open a detailed modal listing every impacted object.

You can export your Playbooks Run history to CSV. The export will include the ID of the enrolled object, the object type (e.g., user, note), the run status, and the entered and exited timestamps.

If the run was manually stopped by someone on the team, we'll display the name and email address of that user. We also include the MRR and ARR of the account, or the parent account the enrolled object belongs to, along with the organization's MRR and ARR if your Vitally instance has hierarchy enabled.

You'll be sent an email with a link to download the CSV. The link expires after 1 hour, so be sure to check for it. If you do not receive the CSV, you may be unsubscribed from Vitally emails. Reach out to Support, and we can resubscribe you!

Selecting Export all Runs will export all In Progress, Completed, and Stopped run history in the same CSV. Selecting the option to Export the current list of Runs will export the run history for the selected tab that you're on. For example, if you're viewing the Stopped run history, only Stopped run data will be included in the export.

You can stop a Playbook automation. This action has two impacts:

When you delete a Playbook, here's what will happen:

There may be times when you want to stop a Playbook from running on a customer, user, task, or other object. You can manually stop a Playbook's run.

We'll display the name of the user who manually stopped the run, along with the date and time the run was stopped, in the first node of the Playbook when viewing a run that was stopped.

Here's how:

For users, accounts, or organizations:

For Tasks, Projects, and Other Activities:

Playbooks can be paused manually using the toggle in the upper right corner, and will be automatically paused when changes are saved. Pausing a Playbook does not automatically undo any actions previously applied.

While a Playbook is off, any pending conversations that have already been generated will continue to be sent at their previously scheduled send date. Sending is not paused.

Segments will remain applied, and Key Role will remain assigned.

Any activity items, like Tasks or Projects, will continue to have a scheduled due date.

Wait actions will pause, and will pick up where they left off. For example, if an account is 2 days into a 7-day wait, they will continue on the remaining 5 days once the Playbook is enabled again.

An undo strategy can be configured for actions like conversations, tasks, projects, and notes. There are two options to select from: Delete or No Action.

If you select the option to Delete, this will remove the activity item (pending conversation, incomplete task/project, Doc, etc.) once the customer stops matching the trigger rules for the Playbook and exits.

Selecting the No Action option will leave the activity in place, even if your customer exits the Playbook.

The Update task(s) action lets a Playbook modify existing tasks at the target Account, Organization, or User — including updating their Task status. It is available on Playbooks regardless of trigger type.

Q: I applied an action retroactively after making a change. Why were all actions not applied?

A: When a Playbook gets retroactively applied, it applies all new actions that have not yet been applied to matching objects. It doesn't rerun any actions that have already been applied to a matching object.

Q: Do churned customers run through playbooks?

A: As of 12/8/23, all actions will be applied for any Playbook created on or AFTER. You'll want to add a filter such as 'churn date is not set' so those actions don't trigger on churned Organizations or Accounts.

Any Playbooks created before 12/8/23: Yes, but not all actions are applied to churned Objects. Below is a list of actions that a Playbook will ignore and actions that will work via a Playbook:

Q: How do I stop churned customers from being enrolled in Playbook automations?

A: Churned customers will be enrolled in playbooks, and all actions will apply. If you don't want your playbooks to include churned enrollees, simply add a filter for "Churn date is not set" for Orgs and Accounts or "Deactivated is not set" for Users if your lifecycle tracking rules have been configured.

Q: I'm using the action filters to reply to a conversation earlier in the playbook, but can not find the conversation I want to reply to. What's going on?

A: This is likely tied to the "strategy" in your conversation action. You want to be sure to have it set to "start a group conversation with users at the same account" and NOT "start one conversation per user". Once you switch that over to the appropriate strategy, you will now see the conversation under the action filters.

This is specifically the case for account- and org-level Playbooks: because the Playbook evaluates at the account/org level rather than per user, individual recipients can't be evaluated in branching logic. Only group conversations can be referenced by an action filter in these Playbook types. If you need to reference a conversation through an action filter and want to use a 1-1 per-user strategy, a user-level Playbook would be the better fit.

Note: if the Strategy field itself appears greyed out and can't be changed, see the next FAQ entry below.

Q: The Strategy field in my "Start a Conversation" action is greyed out and I can't change it. Why?

A: The Strategy field becomes locked when the conversation created by that action is being used as an action filter elsewhere in the same Playbook. To change the Strategy, you'll first need to remove the action filter that references this conversation, update the Strategy to the desired option, then re-add the filter.

Keep in mind that on account- and org-level Playbooks, only the "start a group conversation" strategy can be referenced by action filters — see the FAQ entry above for details.

Q: Why am I not seeing my target audience?

A: Some filters, like Events during a timeframe, take a very long time to calculate, and therefore, results can not be returned in a timely manner.

Q: My Table View uses the same datetime filters as my Playbook's trigger rules, but the matching records don't line up. Why?

A: When a datetime trait is used in Playbook trigger rules, the comparison against the current date and time uses UTC. In Table Views, the same datetime filter compares against your local timezone. Because of this, a Table View built with the same filters as a Playbook's trigger rules can match a different set of objects, especially near the boundary of a time window. To confirm exactly who matches a Playbook, use the Matching Audience preview on the trigger rather than a Table View.

Q: How is "less than N days ago" counted in a date or datetime filter?

A: The comparison is counted by calendar day, not by an exact rolling window of N×24 hours. "Less than 2 days ago" means the value falls on yesterday or today, regardless of the time of day. For example, if today is June 22, "less than 2 days ago" matches any value dated June 21 or June 22, at any time on those days. This is true whether the filter is in a Playbook's trigger rules or in a Table View or widget. The only difference between the two is which timezone defines "today": Playbook trigger rules use UTC, while Table View and widget filters use your local timezone (see the previous FAQ entry).