Hello everyone. I am creating a new training module for our digital channel administrators. We are adding the WhatsApp integration to our course. I need to explain the WhatsApp 24-hour customer service window rule. If a customer sends a WhatsApp message, the agent has exactly twenty four hours to reply with a free form text. If the agent replies after twenty four hours, WhatsApp blocks the message because it requires an approved template. My question is about the Architect inbound message flow. How can I build a routing check in the Architect flow to verify if the 24-hour window is still open before routing the message to an agent, so we do not waste the time of the agent with blocked conversations?
I run a tiny contact center and this exact rule has caused so many headaches. I am the only administrator here. We had agents trying to reply to WhatsApp messages from Friday night on Monday morning, and every single message failed.
The worst part is Genesys Cloud still counts it as a handled interaction even though the customer never got the reply. You cannot check this 24-hour timer natively in the Architect message flow using the standard blocks.
The platform just blindly routes the conversation. I had to build a custom Data Action to query our CRM database, check the last message timestamp for that phone number, and then disconnect the flow if it is over the limit.
It is a ridiculous amount of work for a basic channel requirement.
Hello. Building training for WhatsApp is fantastic! That is correct that you cannot check the timer directly with a standard flow block, but you do not need a complex CRM database either! You can use the Genesys Cloud Data Actions to query the Conversation API directly from your Architect flow! You just configure a Data Action to hit the /api/v2/conversations/messages/{conversationId} endpoint, extract the timestamp of the last customer inbound message, and compare it to the current system time using an expression in a Decision block. If the time difference is greater than twenty four hours, you automatically route them to a bot that sends the approved WhatsApp template to restart the conversation! It is a brilliant way to automate the compliance rule!
3 Likes
The Data Action approach mentioned above works, but it’s a sledgehammer for a nut. You’re adding latency and complexity to every single inbound message just to check a timestamp. Plus, you’re relying on the Conversation API which can be slow under load.
You don’t need a Data Action. You need the lastInboundMessageTimestamp property that’s already on the Conversation entity in Architect. It’s right there in the context.
Here’s how you do it without calling any APIs:
- Add a Set Variable node.
- Set
lastInboundto{{conversation.lastInboundMessageTimestamp}}. - Add a Condition node.
- Check if
{{now()}} - {{lastInbound}} > 86400000(milliseconds).
If true, you’re outside the window. Route to a template approval queue or block the agent reply.
// Architect Expression
{{ (now() - conversation.lastInboundMessageTimestamp) > 86400000 }}
This is instant. No HTTP calls. No timeout risks.
The only catch? If the conversation was created via a different channel and migrated, or if there’s a glitch in the platform’s timestamp sync, this might be off by a second. But for 99.9% of cases, it’s accurate enough.
Don’t overengineer this. The platform gives you the data. Use it.
Also, remember that WhatsApp counts the 24 hours from the last customer message, not the conversation start. The lastInboundMessageTimestamp handles that automatically. If you use conversation.startTime, you’ll block agents too early.
Test this in a sandbox first. I’ve seen edge cases where the timestamp doesn’t update immediately after a message is sent, but it’s rare.
Stick to the built-in properties. They’re there for a reason.
Check that lastInboundMessageTimestamp value before you build the flow. It’s not always what you think it is.
In outbound ops, we deal with timestamp drift all the time, and WhatsApp is no different. That property often reflects the time the message hit the Genesys Cloud platform, not the time it arrived in the user’s WhatsApp app. If there’s any latency in the webhook ingestion or the edge processing, your 24-hour window calculation will be off.
You’ll end up blocking valid replies because the system thinks the window closed an hour early. Or worse, you’ll let a template-free message through because the clock reset on a system ping rather than actual customer input.
If you’re going down this path, you need to pull the actual timestamp from the specific WhatsApp message object, not the conversation header. It’s more work. It requires a Data Action or a script step to fetch the last user-sent message and parse its metadata.
But it’s the only way to be safe. Relying on the conversation context timestamp for compliance windows is a recipe for blocked messages and angry agents.
1 Like