Fourteen Spaces, 300 Lists, and a Confidential HR List Everyone Can See
Northwind Robotics (210 employees) is moving off spreadsheets and email, and you are the Workspace owner. A 30-person pilot ran for six weeks without any structure. It produced 14 Spaces, 61 Folders and roughly 300 Lists, many still named "New Folder" and "List". Nobody documented naming or status conventions, and two of the 14 Spaces are near-duplicates of each other. Engineering and Sales both use a status called "In Progress", but they mean different things by it. Client Services needs 40 external client contacts to submit requests and see only their own requests. HR keeps investigation notes that only three people should ever see - yet a new Client Services hire mentioned an HR List appearing in their search results. Leadership has asked you to "collapse everything into one Space so reporting is simple", and wants the cleanup finished before the remaining 180 employees are onboarded in three weeks.
1. How do you investigate why the Client Services hire could see the HR List? Give the order of checks and what you do once you have confirmed the cause.
Read the worked answer
Work from the widest possible cause to the narrowest, and verify with a test account rather than relying on a description of what the user saw.
- Role first. Confirm the hire's Workspace role. Owners and admins sit above most sharing restrictions, so if the person was invited as an admin, correct the role before investigating anything else - otherwise every other finding is noise.
- Container privacy. Ask where the HR notes actually live. Privacy is set per container: a Private Space hides everything inside it, but a private List inside a public Space still lives in a Space the whole company can see. Search results, mentions and notifications from that List must be tested, not assumed.
- Sharing. Check whether the Space, Folder or List was shared with a group the hire belongs to, with everyone in the Workspace, or through a public link. Group membership is the usual culprit after a reorganisation.
- Contain, then repair. Remove the access, check the audit trail for what was actually opened, and check comments, attachments and notifications already pushed to the person.
The lesson for the cleanup: HR content belongs in its own Private Space with an explicit member list, tested as a non-admin before 180 people are onboarded.
2. Leadership wants everything flattened into one Space. Assess that request and propose what you would do instead.
Read the worked answer
The goal behind the request - reliable cross-team reporting - is valid. The proposed mechanism destroys the thing that makes ClickUp readable.
Why one Space fails: statuses are configured per Space and inherited downward. Flattening Engineering, Sales, Client Services and HR into one Space forces one shared vocabulary onto four very different workflows: either "In Progress" has to mean the same thing everywhere, or every team loses the status that describes its work. You also lose a clean permission boundary - a single Space for everything makes 40 external client guests and three-person HR access much harder to scope. Very large Lists also make Board and Calendar views slow and unwieldy.
What to propose instead:
- Consolidate 14 Spaces into roughly 5–7 by function, merging the duplicate pair first.
- Standardise status sets per Space, and publish a one-page mapping so "In Progress" in Engineering and in Sales are documented as different states.
- Unify a small set of shared Custom Fields (Client, Work type, Billable, Due) so cross-Space reporting works.
- Build the reporting on top: an Everything-style view plus Dashboards that pull widgets from multiple Spaces, rather than one giant Space.
Reporting is a view-layer problem, not a hierarchy problem. Say that explicitly, because "one Space" is usually someone asking for a dashboard without knowing the tool.
3. Write the three-week cleanup and onboarding sequence. What happens in what order, and what is the biggest risk?
Read the worked answer
Week 1 - freeze and decide. Stop new Spaces being created (make it a stated rule, not a hope). Interview the owners of each of the 14 Spaces for what they actually use. Agree the target taxonomy: Space names, Folder conventions, status dictionary, shared Custom Fields. Publish it before touching data, because rework is the expensive part.
Week 2 - consolidate. Merge the duplicate Spaces, rename or archive pilot debris, and move live Lists into the agreed containers. Build two or three templates with the correct fields and ClickApps baked in, so the next 180 people cannot recreate the mess. Fix the HR permission issue in this week, not later.
Week 3 - verify and onboard in waves. Test the whole structure with a non-admin test account playing each persona: an engineer, a returns rep, a client guest. Onboard in groups of 40–50 with a 20-minute session and a one-page cheat sheet, and keep a named owner for questions.
Biggest risk: onboarding all 180 on day 21 with no verification pass. Permission and naming problems become exponentially harder to fix once everyone has created content. Second risk: archiving something without export, so agree a rollback point before anyone deletes anything.