A flexible approval structure developers could build
The problem
My first design was simple: create a message and it sends at the set time. The client needed sign-offs, and different units and client accounts needed them in different places, depending on their size and level of trust.
The solution
I worked through the model over several days of discussion with the backend developer, aiming for a structure that matched real-world needs and was realistic to build, rather than one that only looked good on screen. We agreed on three system admin types, three department setups, and automatic escalation when a department has no approver of its own. VIP client accounts fit into the same model, with an optional final approval from the provider.
On screen, approvers review each ad group with a live message preview, then approve, or reject by picking a preset reason such as "Message content is not appropriate" and adding a note. A rejected campaign goes back to its creator showing the reason and note, ready to fix and resubmit. Every campaign carries one of nine statuses, from Incomplete and Pay Pending through Final Approval Pending, Scheduled, Running and Paused to Completed, and running campaigns can be paused, resumed or terminated, with a warning that termination can't be undone.
Why it works
One permission system covered every business unit's and client's setup without separate builds, and because the logic was agreed with the backend developer first, the handoff carried decisions the team already owned, not just visuals.


















