Treating WhatsApp Templates as Configuration Roles
Technical IDs are not business language
A workflow can send a WhatsApp template by storing its provider identifier in a node. That works until different campaigns need different approved templates for initial contact, reactivation, reminders, or appointments.
At that point, the workflow has learned a detail it should not own.
Name the role, resolve the details
I prefer logical roles such as these:
initial
reactivation
qualification_reminder
appointment_reminder
The sending workflow asks for a role. The campaign runtime resolves that role to the appropriate template and message context. A template can then be replaced without changing workflow logic, and different campaigns can share the same send path while using different approved content.
The role alone is not enough. The runtime may also need the right messaging account, sender, language, variable mapping, and service configuration. Those are campaign runtime details, not scattered constants.
What I learned
A provider-specific identifier should not become the business interface by accident. The workflow cares about the purpose of a message; configuration resolves that purpose into the current delivery details.
What should happen next
I want validation before publication that checks required roles, template status, language, variable shape, and messaging context. A missing role should be a publish-time error, not a surprise during a conversation.