In this article
The question
I want a seller to be able to approve a playbook and still say, "This person should wait." The audience, sequence and proof can make sense while one recipient has replied, booked a meeting or asked for no further contact.
The approval I want to ask for has a clear scope. A person reviews the plan we intend to follow. Each recipient's circumstances still need a judgment when the next action becomes possible. Adding people later calls for another judgment about their circumstances.
This is also a limit on what a preview can tell the reviewer. A sample of choices can help someone understand the plan. I want the product to be clear about which people were examined, what was checked and what completing the check will do.
Approval needs to leave room for judgment
The tradeoff between shared control and seller freedom appears in an r/sales discussion about sequence creation[1]. u/isthatashark warned[2] that "Giving everyone Outreach is a good way to create massive deliverability problems for your company's domain." u/garth_b_murdered_me described[3] working at an organization where anyone could add sequences and said, "I wouldn't say it caused any issues."
These are conflicting, self-reported experiences. They do not establish the best approval policy. I take the disagreement as a reason to make the decision under review explicit. A team can need consistency in its plan while leaving a seller responsible for the person they are about to contact.
My read is that approval should tell the seller what has been judged and what still needs checking. A generic approved label cannot explain whether a new reply, meeting or contact preference changes this person's next step.
Consider a fictional team adding people to an approved playbook. One person replied yesterday. Another has a meeting next week. A third has asked the company to stop contacting them. A fourth may fit the purpose but has no usable address. The plan can stay the same while those people need different outcomes.
Review the plan and the person separately
For the plan, I would review its purpose, audience, sequence, channel, sender and proof. I would ask whether the copy makes promises we can support and whether the response paths make sense.
For the person, I would want the latest relevant context. Who owns the relationship? Is there a reply, meeting, contact restriction or reason to wait? Is the channel usable? Does this sender have enough context to act?
The result should have a reason and an owner. "Start," "wait," "review" and "do not contact" are useful when a seller can see what led to them. A contact restriction must be handled through the relevant preference and controls; it should not disappear because someone approved the plan earlier.
| Record I would include in a controlled review | Question for the reviewer | Possible next action |
|---|---|---|
| Recent reply | Did the reply change what the person wants? | Pause and review the reply. |
| Existing meeting | Who owns the conversation? | Coordinate with the meeting owner. |
| Missing address | Is a usable channel available? | Hold until the record can be checked. |
| No concerning context found | Are sender, time and first step appropriate? | Proceed under the approved process. |
I would add a current customer and a record with incomplete research to that review. With a current customer, I would check whether the relationship is visible. With incomplete research, I would check whether an unknown has become a reason to contact. These are proposed review cases, not tests that this article reports as passed.
What the current preview can establish
Mach's dry run calculates a person's group, first action, sender and available time in their time zone. Before an initial run, it works out first-step choices for up to the first 200 people who would start, in addition order. It stores rows and samples without writing a personalized message or sending one.
That is narrower than the judgment I want a seller to make about the whole audience. The first 200 should not be assumed to represent everyone. Their choices also do not show final personalized copy that has not been written.
There is another consequence to understand when the playbook has already run. A later dry run checks newly added, not-yet-tried people without rebuilding the original choice samples. Finishing it can enroll eligible additions in the playbook, including while it is paused. The join creates their run records; the paused-state rule holds their activity. An archived playbook joins nobody.
| Situation in the inspected source | What the check does | What I would want the reviewer to understand |
|---|---|---|
| Before an initial run | Works out choices for up to the first 200 starters. | The sample follows addition order and has a limit. |
| People added after a playbook has run | Checks the additions without rebuilding the original choice samples. | Finishing the check can enroll eligible additions. |
| Already-run playbook is paused | Can enroll eligible additions; activity is held while paused. | Enrollment and sending are separate actions. |
| Archived playbook | Refuses a new dry run and joins nobody. | The archived plan does not start these people. |
I want those consequences visible before the seller begins the check. Whether the current interface explains them clearly was not tested for this article. The source behavior and preview limits need to remain part of the review, even when the plan itself looks sound.
Keep the reason close to the action
The run service checks drawing freshness, open questions, step approval and whether added people have been tried. Person rules separately consider open deals, opt-outs, meetings, other running playbooks and usable channels.
A label in the review does not always enforce a restriction. In the inspected dry-run view, research's "set aside" line is displayed as context rather than a universal sending prohibition. I want the seller to understand which rule prevents an action and which finding needs their judgment.
A preview also ages. Someone can reply, book a meeting or change a preference after it finishes. My bar is that the team can inspect the next action using the relevant current information, with an owner who can stop the run and investigate an unexpected result.
For comparison, Microsoft documents[4] an option to disconnect a Dynamics 365 record from its sequence after a customer replies to an email in it. It must be enabled and has prerequisites, including configured email engagement. That is a configured Microsoft feature, not evidence of Mach's configuration.
Before relying on a workflow, I would use a controlled test person, change a relevant fact after review and inspect the next proposed action and reason. I would repeat that for a reply, a meeting and an explicit stop request. This is a suggested test, and it was not performed for this article.
What changes when a buyer says no? covers the later response. Who is already talking to this buyer? covers the relationship behind a hold.
How this post was made
AI assisted research and drafting from the supplied product rules. Public passages and source version 58fc9baf04e8 were reviewed on 5 November 2026. The recipient examples and review framework are illustrative. No dry run, deployed-interface review or connected-provider test was performed for this post. My statements about the approval experience describe the bar I want the product to meet.
What would a reviewer need to know about a newly added person before letting their first step begin?
Common questions
Does approving a playbook approve every future contact?
The approval covers the reviewed plan and whatever scope the team's process defines. A person added later can have a reply, meeting or restriction that requires a separate decision. Make that decision visible rather than treating a new list as identical to the original audience.
Does a sample prove every record is correct?
It provides evidence about the records examined. Check its limit and selection method, then deliberately review cases likely to behave differently. In the inspected initial Mach dry run, the choice sample covers up to the first 200 starters in addition order, which can miss later groups.
Does a dry run always have no operational effect?
Check the implementation. In the inspected Mach source, completing a dry run for an already-run, non-archived playbook can enroll eligible additions. It does not send a message itself. Understand that distinction and the deployed controls before initiating one.
What happens if we add people while the playbook is paused?
The inspected code permits eligible additions to join after their dry run, while the paused-state rule holds activity. Review those additions before resuming. This source finding does not establish how every connected sending provider handles work that was already queued.
Is a research “set aside” label a contact restriction?
In the inspected dry-run view it is displayed as research context, rather than enforced as a universal bar. Use the appropriate restriction for a real stop request. Review which specific rule prevents the action instead of relying on the visual similarity of two labels.
Should a dry run show the final message?
Find out what the preview contains. The inspected Mach task calculates placement and choices without generating personalized copy. A reviewer who needs to approve the final wording must see it at the relevant writing or approval stage; an earlier preview cannot substitute for that review.
What should the team monitor after starting?
Watch new replies, meetings, preference changes, unexpected holds and records requiring a person's judgment. Name an owner who can stop the run and investigate. Recheck the actual next action after a material change, including the provider responsible for carrying it out.
Sources and further reading
- Who can create outreach sequences at your org?Reddit / r/salesBack to text
- isthatashark warns about sequence access and deliverabilityReddit / r/salesBack to text
- garth_b_murdered_me describes open sequence creationReddit / r/salesBack to text
- Exit a sequence during the flowMicrosoft LearnBack to text
