Next, I had to decide how to group Actions Required. I first considered letting admins group actions manually, but with 20+ actions per review session, that wouldn’t scale — and different admins could group the same actions differently. Since resolving one action in a group resolves the whole group, that inconsistency could change what a resident was agreeing to submit depending on who reviewed their case. Instead, I grouped actions automatically by what they’re about — a Site Plan, Property Deed, or other document or form — rather than leaving it to admin judgment. Each action already links to its entity when it’s created, so the system could use that relationship to determine its group automatically. For each group, I designed a parent component whose status depends entirely on its children — it can’t be resolved until every child action is resolved. I also handled single-action groups: if a group contains only one action, the parent wrapper collapses into the individual card to avoid adding visual clutter without adding meaning, while the underlying data still treats it as a group. One edge case remains: two different entities that are still related, like a plan revision that also needs an updated deed. These currently stay as separate groups, which could cause a similar double-submission problem. I want to test this against real cases before deciding whether it needs its own solution.