#High Velocity Sales2 discussing

The toggle only switches the feature on. Users see nothing until they have access and a console app to use it in. Three things to check: 

1) Permission sets. In Setup > Permission Sets, assign Sales Engagement User to reps and Sales Engagement Cadence Creator to whoever builds cadences, including yourself. On Unlimited and Performance editions the names end in "Included" (Sales Engagement User Included, Sales Engagement Cadence Creator Included). 

2) A Lightning console app. Sales Engagement runs inside the Lightning Sales Console, and the Work Queue only shows in a console's split view. In App Manager, edit the Sales Console (or your own console app), check it is assigned to your profile on the User Profiles tab, and open that app from the App Launcher rather than looking for a separate Sales Engagement app. 

3) Log out and back in after assigning the permission sets, so the new access loads. 

If your reps work from Outlook or Gmail, the Work Queue can also be added to the email integration pane through Setup > Outlook (or Gmail) Integration and Sync with Customize Content with App Builder turned on.

It actually is possible, but it needs done with via the API since the object isn't available to customize via UI 

This is the Idea to upvote but honestly I don't see them optimizing the cadence objects any time soon for us admins. They provide a link to a guide so you can adjust using workbench. 

@Mille Bonekamp

correct, the Load Engagements button will expand to display five categories - calls, emails sent, email replies, link clicks, and opens. You can then click on those icons to further expand the timeline to see related records.  

It's basically what you see in the Activity Timeline but in a different format. 

The setup for Sales Engagement is fairly customizable in that you don't have to turn on everything if you don't want to... we only use it with EAC for emails. We don't have a telephony solution connected to it, I never turned on Insights because I think it's garbage, we didn't do lead scoring.. you really only need to focus on the Automate and Email tabs of the setup. 

@Clay Crepps

The issue is what "wait for 7 days (advance when target engages)" actually does. That setting is not a 7-day listening window that must fully elapse before moving on. It's a maximum wait with an early-exit on engagement. But critically, the branching logic evaluates as soon as the step's own timing conditions are met, and your next step's schedule then applies from that evaluation point, not from the end of a full 7-day window.

What you intended was: listen 7 days, then wait 1 more day, then send at day 8. What actually happened is the branch evaluated much sooner and your "1 day after at 10am" scheduling kicked in from that earlier point, landing your follow-up emails on day 2.

The specific mechanic causing the day-2 send is the interaction between the wait duration on the listener step and the start timing on the next step. Your step 3 is configured to start 1 day after at 10am. That "1 day after" is relative to when the previous step completes or branches, not relative to the full 7-day window expiring. Since the No-reply branch evaluated at the end of day 1 rather than day 7, adding your 1-day offset produced a day-2 send for everyone who hadn't replied.

Here's how to get the behavior you actually want.

The cleanest fix is to consolidate the timing into a single place rather than splitting it across the listener duration and the next step's start offset. Set your wait/listen step to the full 8 days if you want the follow-up on day 8, and set the follow-up email step to send immediately when the No branch is taken rather than adding another day offset. That way there's one number controlling the timing and no compounding or mis-anchoring between two settings.

Alternatively, keep the 7-day listen but change step 3's timing from "1 day after" to a same-day send, then verify in a test run when the branch actually fires. The reason I'd lean toward consolidating instead is that it removes the ambiguity entirely rather than relying on you correctly predicting the anchor point.

Before you rebuild, do this diagnostic: pull up one of the targets who got the follow-up on day 2 and look at their cadence step history. It'll show you the exact timestamp when the listener step completed and when the branch was taken. That timestamp tells you definitively what the "1 day after" was anchoring to, and confirms whether the wait step exited early or the offset anchored somewhere you didn't expect. That's worth doing so you're fixing the actual mechanic rather than guessing.

Also worth checking: confirm the wait step is genuinely configured for 7 days and not carrying a default that got overridden when you set the branch conditions. It's easy for the duration to not save as expected when you're also configuring the engagement-based advance on the same step.

Test the rebuilt cadence on a small group of two or three targets before running it on your full list, so you can watch the actual send timing rather than discovering it at scale again.

We've run into similar call logging scenarios when integrating telephony with Salesforce. In many cases, the phone system creates its own Task record, which doesn't automatically update the existing Sales Engagement Cadence task. 

If keeping call logs tied to the same Salesforce workflow is important, it's worth looking at how the CTI integration handles task updates and activity logging. 360 CTI is one option that supports Salesforce-native call logging and configurable activity association, so it may be useful if you're evaluating alternatives or need more flexibility than your current setup provides. 

It would also be interesting to hear if anyone has been able to achieve this with Zoom Phone using configuration alone. 

Hi @Dana Breakstone,

Based on my experience with Sales Engagement Cadences:

Question 1

The 24-hour restriction generally applies when you have consecutive

Question 2

For your workflow, the listener duration and the next step timing work together. If your listener is configured to monitor

For example:

1. Automated Email (Immediately)
2. Listener: Email Link Clicked (Wait 12 hours)
   • If clicked → End Cadence (or branch accordingly)
   • If not clicked after 12 hours → Continue
3. Automated Email (Immediately after listener expiration)

This avoids introducing an unnecessary additional delay. If you set Step 3 to "12 hours," the prospect would actually wait approximately 24 hours (12-hour listener + another 12-hour delay).

If you're seeing the 24-hour validation even during testing with shorter intervals, it may be due to the platform's minimum interval requirement between automated email actions rather than the listener itself. I'd be interested to know if anyone has found an official Salesforce document that explains this validation in detail.

Hi Isma, I'm not a Spiff user, but if Spiff follows the same release best practices as other Salesforce products, the best way to learn the details of product updates is to view the official release notes pages:

I am not aware of proactive notifications, although some products have release readiness emails you can subscribe to. It's part of the admin's responsibilities to proactively inform themselves on product changes whenever release notes become available! Hope this helps.