Ability to have CTA Due Date exceptions for black-out dates (i.e. holidays) much like "skip all weekends"

When assigning CTA Due Dates via Rules Engine, we currently have the option to “Skip Weekend if Due on a Weekend”, or “Skip All Weekends”.  My end users have asked to have an Exception Calendar that could also be skipped for Holidays, or shut-down periods, etc.

@travis_floyd valid request, I am voting for this and redirecting to product team. 

@All, please up-vote here and show your interest on this enhancement. 

@sai_ram it would be great if the admin could create this and set it to the user as well. We are a global company and our EMEA, APAC, and North America teams have different holidays to consider

Hello there, this is a valid but niche use case. We will pick this up based on the upvotes. Thanks.

@sriram pasupathi  I do not think it is that niche of a use case. How weird would it be to get an email response from a CSM on a Saturday when they know our company is not in the office? Or on Christmas day when they receive an OOO reply?


If we want to use JO to scale our CSMs communication, it should align when a CSM would communicate which is not on a weekend or a company holiday. Other automation email programs have the ability to “black out” dates

@andreammelde I’m sorry I didn’t understand the ask properly. I am assuming that you want to choose off days other than the weekends. Am I correct?

@sriram pasupathi yes - we want the ability to skip weekends and specified dates. The idea is that the email would remain in the queue until the next day that is not “blacked out” and would send at a later time. 


This would also help with internal emails. We have notifications send to teams not in GS so they are aware of things on going with the CSM. It would be helpful to ensure these do not get sent over the weekend so that they do not get buried in other emails

@sriram pasupathi and @sai_ram I didn’t see this one when I made my post, but I have a similar but broader request here too: 


Thanks for the feedback. We will evaluate this from our side from rules engine perspective. @rakesh