Designing a Governed Account Structure After Rapid Growth
Northwind Services has grown from 40 to 420 employees in 18 months. Each of six delivery teams built its own board for the same client onboarding process. There are now 23 boards, four different status label sets (Done, Complete, Closed, Finished), and client names typed three ways. The two account admins cannot answer which onboardings are late without exporting to spreadsheets. Guests from client organizations are invited directly to boards, and one guest can see another client's project because a board is shareable. The company is moving to Enterprise and wants a structure that supports cross-team reporting, least-privilege access, and reuse without locking teams into one rigid process. There are 2,000 active items, six proposed workspace owners, no dedicated admin team, and a four-week migration window. Delivery cannot pause during migration.
1. Recommend an account structure and permission model for Northwind. Justify the hierarchy and explain how guests should be handled.
Read the worked answer
Use Workspace > Folder > Board deliberately: one Client Delivery workspace for the delivery org, folders per client segment or region, and boards per onboarding type (standard, enterprise, partner). Do not create one workspace per team, because cross-team reporting and template reuse become fragmented. Put the shared client list in a single Clients board in the same workspace; connect onboarding boards to it with a Connect Boards column and expose client name and owner through Mirror columns. Use board templates with a controlled status set (On Track, At Risk, Delayed, Done) and required fields. Permissions: keep source boards private to delivery members; invite client guests only to a dedicated client-facing board or a filtered shareable view, never to the workspace. Workspace owners manage membership; account admins stay limited to two. Use a naming convention such as Region-Client-Onboarding and archive completed boards quarterly.
2. Teams want to keep their own client name text column because it is familiar. Explain the trade-off and recommend a data design for client names.
Read the worked answer
Keeping a free-text client name on every board preserves local convenience but recreates the exact problem: variants, typos, and no reliable grouping. A central Clients board with a Connect Boards column creates a relationship rather than a copy; the client record is edited once and referenced everywhere. Mirror columns then surface client owner, tier, or region on the onboarding board for filtering and dashboards. Explain the limitation: mirror values are read-only at the destination, so teams must edit the source Clients board. Also define who can create clients and require a unique key such as client code. If a team truly needs a local label, make it a formula or a status derived from the connection, not an independent text field. This keeps reporting accurate without forcing every team into identical board layouts.
3. Outline a four-week migration that does not pause delivery. What should be standardized first, and what should be deferred?
Read the worked answer
Standardize the minimum reporting contract first: status labels, client identifier, project owner, start and due dates, and archive rules. Defer cosmetic column names and team-specific views. Week 1: build two templates, the Clients board, and one pilot folder; map old statuses to the new set. Week 2: migrate one team in parallel, keep the old board read-only, and test dashboards. Week 3: migrate remaining teams in waves, with workspace owners doing the mapping and admins validating permissions. Week 4: freeze old boards, run reconciliation counts, train on the new templates, and archive. Do not bulk-move 2,000 items without a mapping table; do not delete old boards immediately. Keep a rollback board and a known-issues log. Communicate that delivery work continues in the new board only after the pilot check passes.