Emails from staff about branch-level decisions may get lost in piles of other emails and maybe not seen by your manager in a timely manner. Therefore, it is essential to follow up by sending another email for confirmation that the first was seen, or marking the initial email as a priority, or swinging by your manager's office to let them know you sent them a detailed email regarding a recent decision that you'd like them to review in case there are any questions or concerns so they can be addressed as soon as possible and before reversing it could be a real issue.
Once you decide to apply a model like this, the next step is to engage your staff in interpreting it and customizing it to their environment. That might start with asking each of your direct reports to define what they believe are the four different levels of decisions that they make, including examples. You collectively begin to see what the model really looks like, and can collaborate to make changes or edits from there.
That gives you a starting framework within which to operate. Assume that working this through and making it effective is an iterative process, and that people will interpret things differently and will make some mistakes.
For example, one of your people makes a decision, and they assume it's a leaf decision and they don't inform you. You find out about it a few days later, and say "Hmmm, I really would have liked to have known about this." You and he can sit down and he might say "Well, here I thought it was a leaf decision because...". You could then say "Well, in this particular case, even though I didn't need to approve it, this is the kind of thing I would like to know about fairly quickly," and you can discuss the reasons why. With this framework and process, you learn from each other, and you align yourselves around what these decisions rights actually mean.
This can also become a communications framework for your staff meetings. It's a way for your team members to decide what information should be shared in these meetings, and in which issues or decisions the rest of the team needs to be engaged.
Decisions that you need to make collectively might be trunk decisions. Decisions that you don't need to make collectively but everyone needs to be aware of might be branch decisions. And then leaf decisions wouldn't come up in these meetings at all, as they are day to day operational decisions that would normally stay within each department.
Using IT Operations as an illustration: Standards tend to be either root or trunk decisions, in that you either need to make them, or you need to approve them. All of your directs need to be involved in the decision-making process, because setting standards impacts everyone on a fundamental level.
Sign up for MIS Asia eNewsletters.