Skip to main content

SC Task Management Workspace Setup SOP

1. Purpose & Scope​

Single rebuild-from-scratch reference for the Symphony Core task-management workspace. Anyone with workspace-admin access should be able to follow this SOP top-to-bottom and reach a fully-configured workspace that matches the canonical SC operating model.

In scope:

  • Workspace-level configuration (ClickApps, tags, members, integrations)
  • Status template sc-status-01 — the canonical status set used by every list
  • Client Delivery space — per-client folder + list pattern
  • SC Operations space — internal work
  • Smoke-test sequence to verify the setup
  • Tool-portability appendix — what to preserve when migrating off ClickUp

Out of scope:

  • Per-client list customizations (handled by the client onboarding flow, not workspace setup)
  • GHL pipelines (a different system; see 05-platform/platforms-config/)
  • Workflow-level automation builds (separate PRDs)
  • Sales prospecting space (its own configuration, not covered here)

This SOP is the implementation of the SC Task Data Standard. The standard is tool-agnostic; this SOP shows how the abstract model lands in ClickUp specifically.

2. Data Model (abstract — tool-agnostic)​

The canonical task data model is defined in SC Task Data Standard:

  • Statuses — §1 of the standard. Five states: TODO, IN PROGRESS, BLOCKED, COMPLETE, CANCELLED.
  • Fields — §2 of the standard. Task ID, Title, Description, Status, Assignee, Creator, Start Date, Due Date, Completion Date, Priority, Tags, Relationships, Estimate, Time Tracked.
  • Relationships — §3 of the standard. Parent/Subtask, Blocked By/Blocking, Follows/Precedes, Duplicate Of/Original, Related To.
  • Transitions — §4 of the standard.

Every implementation in any tool must satisfy that model. The rest of this SOP describes how ClickUp is configured to do so.

3. Status Template — sc-status-01​

sc-status-01 is the named ClickUp status template applied to every list in the Client Delivery and SC Operations spaces. It is the single source of truth for status configuration in the workspace.

3.1 Template content​

StatusClickUp groupVisibility behaviorMaps to abstract
to doNot startedVisibleTODO
in progressActiveVisibleIN PROGRESS
blockedActiveVisibleBLOCKED
cancelledDoneVisible (intentional — AM can spot abandoned work during sampling)CANCELLED
completeClosedAuto-hidden from default views (terminal, no longer needs attention)COMPLETE

3.2 ClickUp-specific notes​

  • One-status-in-Closed limitation. ClickUp restricts the Closed group to exactly one status. The two terminal states (complete and cancelled) are therefore split: complete in Closed (auto-hide), cancelled in Done (stays visible). This is a tool constraint, not a model deficiency.
  • Lowercase names. All status names are stored lowercase. ClickUp's UI displays them in uppercase, but the API and filters use the lowercase form. Documents should use lowercase to match.
  • No review status. Validation happens via the Evidence bullet on acceptance criteria at complete, plus a QA-Review subtask for client-facing deliverables (see Markdown Task File to ClickUp SOP §3c). Post-hoc sampling by the AM (per SC Contractor Task Quality Review Standard) is the accountability mechanism.

3.3 Applying the template​

  1. Workspace Settings → Status templates → sc-status-01 — create if absent.
  2. Configure the five statuses per §3.1 above. Order top-down: TO DO → IN PROGRESS → BLOCKED → CANCELLED → COMPLETE.
  3. Save the template.
  4. In each space (Client Delivery, SC Operations), set the space-level template to sc-status-01.
  5. For any list that has list-level status overrides (custom statuses), open its status settings and choose Use space template so it inherits.

4. Workspace-level configuration​

4.1 ClickApps​

ClickAppStateWhy
Multiple AssigneesDisabledSingle-assignee-per-ticket is canonical (see working-rules.md#single-assignee-per-ticket and Markdown Task File to ClickUp SOP §3d). Disabling at workspace level mechanically prevents reintroducing multi-assignment.
Progress iconsEnabledVisual cue for status group; supports linear workflow visualization.
Time TrackingEnabledUsed for the timesheet approval flow (see ClickUp Timesheet Approval SOP).
TagsEnabledRequired for the SC ClickUp Tag Taxonomy.
Custom FieldsEnabledRequired for per-space fields (§5.3, §6.3).

4.2 Tags​

Provision the full canonical tag set at each space level before any tickets are created. The complete taxonomy lives in SC ClickUp Tag Taxonomy. Categories:

  • client/<slug> — one tag per active client in 09-clients/. When to apply (required on SC Operations + Client Delivery shared lists; optional on per-client lists where the Client custom field in §5.3 is the canonical identifier) is defined in SC ClickUp Tag Taxonomy §Client identity.
  • domain:wordpress, domain:seo, domain:dns, domain:billing, domain:ghl, domain:design
  • quality:rework, quality:escaped, quality:partial-met
  • blocked-on:client, blocked-on:vendor, blocked-on:hosting-support

Tags are space-scoped in ClickUp — provision them in both Client Delivery and SC Operations spaces.

4.3 Members & roles​

RoleScopeWho
OwnerFull workspaceSymphony Core principals
AdminFull workspaceAccount Managers
MemberSpaces granted explicitlyInternal SC team
GuestSingle Folder, scoped permissionsExternal project partners — see Project Partner Team Onboarding SOP

4.4 Integrations​

IntegrationStateNotes
GitHubEnabledUsed for linking PRs to tickets
SlackEnabledUsed for @AM ready for review notifications

5. Client Delivery space​

5.1 Purpose​

Tracks all work delivered to clients. Every active client has exactly one folder under this space.

5.2 Structure​

Client Delivery (Space)
├── <client-slug>/ (Folder, one per active client)
│   ├── active-work (List)
│   └── reference (List)
├── client-delivery-operations (List, folderless) — cross-client AM coordination
└── reference (List, folderless) — standing reference items
  • active-work — every ticket for this client, in every status (to do, in progress, blocked, complete, cancelled). The complete status sits in the Closed group (see §3.1), so default views auto-hide it; opt-in views (see §5.5) surface completed work when needed.
  • reference — per-client standing reference items (canonical links, evergreen specs, etc.). Not work in flight; never appears in "open work" views.

Note on retired lists. The completed-work and archive lists were retired in v1.2 of this SOP. Rationale: the Closed-group hide on complete already keeps finished work out of default views (no separate list needed), and per-folder lists with identical names (completed-work, archive) made cross-folder views impossible to build with list-name filters. Cold storage is now handled by ClickUp's native task archive (right-click → archive) via a monthly UI sweep — see §5.6. See the changelog (§10) for the full rationale.

5.3 Custom fields (space-level)​

FieldTypeNotes
ClientReference / DropdownThe client served by this task. Required on every Client Delivery ticket. Populated per markdown-task-file-to-clickup-sop.md §3. See also the tag–field correspondence rule in SC ClickUp Tag Taxonomy §Client identity — the Client field value and the client/<slug> tag (when present) must match.
Delivery RoleDropdownAM / Specialist / Project Partner / Other
BillableCheckboxToggles whether time logged is invoiced to the client
AssigneeBuilt-inExactly one, per working-rules.md#single-assignee-per-ticket

5.4 Status template​

sc-status-01 (see §3). All lists in this space inherit from the space template — no list-level overrides.

5.5 Default views​

All views are status-based — no list-name filters. List-name filters are an anti-pattern in this workspace because per-folder list names previously collided (e.g., the retired completed-work and archive lists shared their names across every client folder).

ViewScopeTypeGroup byFilter
All Open WorkWorkspace (Client Delivery space)BoardClientStatus not in (complete, cancelled)
Recently Completed (30d)Workspace (Client Delivery space)ListClientStatus = complete AND date_done > today − 30d
By ClientWorkspace (Client Delivery space)BoardClientStatus not in (complete, cancelled)
My TasksWorkspaceListDue DateAssignee = Me
Per-folder Completed (this month)Folder-scopedListStatusStatus = complete, sorted by date_done desc

Full filter expressions and naming conventions are documented in ClickUp Views and Filters Guide §6.7–§6.9. The guide is the source of truth for view recipes; this section lists the standard set that should exist after setup.

5.6 Cold storage: monthly native-archive sweep​

No automation here. Earlier versions of this SOP referred to an auto-move rule (complete → completed-work); on inspection during the 2026-06-08 migration, no such automation existed — ClickUp does not support workspace-scoped automations, and no equivalent space- / folder- / list-level rule was found in the configuration. The behavior was always manual. With v1.2's retirement of the completed-work and archive lists, the architecture is now explicitly declarative: status filters + ClickUp's native task archive, no automation surface.

Hot to cold pipeline:

  1. Active state (any duration): ticket lives in active-work. Status drives visibility — complete is in the Closed group (§3.1), so it auto-hides from default views.
  2. Recently completed (under ~30 days): still in active-work with status complete or cancelled. Surfaced by the "Recently Completed (30d)" view in §5.5 when the AM or contractor needs to look back.
  3. Cold storage (older than ~30 days): Account Manager moves the task to ClickUp's native task archive (right-click → Archive Task, or bulk-select in the Recently Completed view and use the bulk action). Native archive hides the task from all default and opt-in views but keeps it recoverable from the list's "Show archived" toggle.

Monthly UI sweep: on the first business day of each month, the Account Manager opens the "Recently Completed (30d)" view, sorts by date_done ascending, bulk-selects tasks older than 30 days, and runs the native-archive action. Estimated 5 minutes/month at current task volume. This sweep is tracked under the pending workspace-cleanup ticket (see 10-people-operations/backlog.md if logged there; otherwise the recurring AM-ops task).

Per rules-first-automation: any future proposal to automate this sweep would need (a) a rule documented here naming the trigger condition (e.g., "tasks with complete status older than N days are auto-archived") and (b) a separate PRD per automation-requires-prd. Until then, the sweep is manual.

6. SC Operations space​

6.1 Purpose​

Tracks SC-internal work that is not delivered to a client. Examples: agency platform configuration, internal tooling, sales prospecting, documentation projects.

6.2 Structure​

SC Operations (Space, id 901313535576)
├── people-operations           (List, id 901326049401)  — contractor onboarding, payments, access, offboarding
├── sc-marketing                (List, id 901327163043)  — SC brand, website, social, marketing content
├── sc-sales                    (List, id 901326361161)  — leads, prospects, pipeline work
├── platform                    (List, id 901326052561)  — ClickUp, tooling, internal platform
├── client-delivery-operations  (List, id 901327216662)  — cross-client delivery work that isn't per-client
├── archive                     (List, folderless)       — cold storage for retired SC-Ops items
└── reference                   (List, folderless)       — long-lived reference notes

Flat structure — no folders. Each list is its own work domain; the list name IS the domain label (no separate Work Domain dropdown needed). If a new domain emerges, add a new list (do not nest under a folder). Status filtering (sc-status-01's Closed-group auto-hide on complete) replaces per-list "completed" lists; cold storage uses ClickUp's native task archive (see §5.6 for the analogous Client Delivery sweep, applied identically here).

6.3 Custom fields (space-level)​

FieldTypeNotes
Sub-AccountShort TextGHL location ID when applicable; blank for non-GHL work
AssigneeBuilt-inExactly one

Fields intentionally excluded (these belong to Client Delivery only): Client, Delivery Role, Billable. Work Domain dropdown is also excluded — the list itself is the domain.

6.4 Status template​

sc-status-01 (see §3) — identical to Client Delivery.

6.5 Default views​

ViewTypeGroup byFilter
All Active WorkBoardStatusStatus not in (complete)
By ListBoardListStatus not in (cancelled, complete)
My TasksListDue DateAssignee = Me
Recently Completed (30d)ListListStatus in (complete, cancelled), date_done within last 30 days

6.6 People-operations list​

People-ops tickets (under 10-people-operations/ — contractor onboarding, payments, access provisioning, registry maintenance, offboarding) default to the people-operations list (901326049401). See 10-people-operations/README.md §Task Tracking.

6.7 Per clickup-structure-sync​

Any future addition/removal/rename of a list in SC Operations MUST ship paired with: (a) an update to §6.2 above, (b) a refresh of memory reference_sc_operations_clickup_lists.md, (c) closure of any tracking ticket. Do not let live state diverge from this diagram.

7. Smoke tests (post-setup verification)​

Run after every setup pass — initial workspace creation, status-template edit, or list-pattern change. Each test takes under a minute.

  1. Create ticket — in any active-work list, create a new ticket. Confirm it lands in to do status.
  2. Status transitions — flip the ticket through in progress → blocked → in progress → complete. Confirm each transition succeeds. The ticket stays in active-work; complete is auto-hidden from default views by the Closed group (§3.1).
  3. Completed-view surfacing — open the "Recently Completed (30d)" view (see §5.5). Confirm the just-completed test ticket appears.
  4. Cancellation path — create a second ticket, mark cancelled. Confirm it stays in active-work and is visible (Cancelled is intentionally not hidden — see §3.1).
  5. Native-archive recovery — on the test ticket from step 2, right-click → Archive Task. Confirm it disappears from default views AND from the Recently Completed view. Toggle "Show archived" on the list, confirm it reappears. Un-archive.
  6. Single-assignee enforcement — try to add a second assignee. Confirm ClickUp blocks the action (Multiple Assignees ClickApp disabled).
  7. Tag application — apply one tag from each category (client/<any>, domain:wordpress, quality:rework, blocked-on:client). Confirm no "tag does not exist" errors.
  8. QA-Review subtask path — on a client-facing parent ticket, add a qa-review-<parent-slug> subtask. Confirm subtask shows up with its own single assignee. (Legacy am-review-* form remains valid; see Markdown Task File to ClickUp SOP §3c.)
  9. Cleanup — delete the test tickets.

If any test fails, revisit the relevant section before declaring the setup complete.

8. Migration to a different task-management system​

If SC ever moves off ClickUp (to Linear, Asana, Jira, Notion, or a custom system), the following are portable and should be preserved:

LayerSource of truthTool-agnostic?
Data model (statuses, fields, transitions)SC Task Data StandardYes — re-implement against the new tool's primitives
Tag taxonomySC ClickUp Tag TaxonomyYes — names and semantics carry over; rename file when moving
Single-assignee-per-ticket ruleworking-rules.md#single-assignee-per-ticketYes — enforce via whatever mechanism the new tool offers
QA-Review subtask patternMarkdown Task File to ClickUp SOP §3cYes — re-implement using the new tool's subtask/dependency primitive
Workspace → space → folder → list → task hierarchyThis SOP §5 / §6Mostly — most tools have an equivalent 3-or-4-level hierarchy; map by name
sc-status-01 template nameThis SOP §3Concept yes, name no — the new tool may not support named templates; configure each project/list directly
Native task archive (cold storage)This SOP §5.6Concept yes — most tools have an "archive" or "soft-delete" verb that hides without losing data
ClickApps (Multiple Assignees, Progress icons)This SOP §4.1No — ClickUp-specific. The intent (single assignee) carries; the mechanism differs

The doc structure of this SOP intentionally separates abstract spec (§2–3.1, §5–6 list of fields and lists) from ClickUp-specific implementation (§3.3, §4.1, §5.6, §7). When migrating, the abstract sections inform the new tool's configuration; the ClickUp-specific sections become reference material.

9. References​

10. Changelog​

DateVersionChangesAuthor
2026-06-021.0Initial consolidation. Replaces clickup-sc-operations-space-setup-sop.md (deprecated). Adds workspace-level config, Client Delivery space spec, smoke-test sequence, and tool-portability appendix. Names sc-status-01 as the canonical status template.Symphony Core Systems Team
2026-06-041.1Reconciled client/<slug> tag vs Client custom field. §5.3 now names the population source (markdown-task SOP §3) and the tag–field correspondence rule. §4.2 cross-references the tag taxonomy's refined when-required rule. The two constructs are now scoped non-overlappingly (field = mandatory in Client Delivery; tag = mandatory in SC Operations + Client Delivery shared lists, optional on per-client lists).Symphony Core Systems Team
2026-06-081.2Per-client folder simplified from 4 lists to 2 lists (active-work + reference). Retired completed-work and archive lists. Status filtering (Closed-group auto-hide on complete) now does the work the completed-work list previously did. Native ClickUp task archive replaces the archive list via a manual monthly UI sweep (§5.6). Default views §5.5 rewritten to use status + custom-field + date filters; no list-name filters. Drivers: (a) cross-folder views were impossible because per-folder list names collided (e.g., every folder had a list named completed-work), (b) the 2026-06-08 Tanu/Rohit meeting confirmed the friction with a hand-built "list include completed" workaround for rotary-sports, (c) Business plan's Timesheet Approvals removed the need for list-movement as a billing-cycle signal. Note: earlier text in §5.6 referred to a complete → completed-work "workspace automation" — on inspection during the migration no such automation existed (ClickUp doesn't support workspace-scoped automations, and no equivalent space/folder/list rule was found); the behavior was manual. Smoke tests §7 updated to include native-archive recovery path.Symphony Core Systems Team
2026-06-141.3SC Operations flattened from folder-based to flat sc-* lists (§6.2 fully rewritten). Retired the Agency Platform/ and Sales/ folder layer; live list set is now people-operations, sc-marketing, sc-sales, platform, client-delivery-operations, archive, reference — all folderless. §6.3 removed Work Domain dropdown (list = domain); §6.5 updated views (By List instead of By Domain, added Recently Completed (30d)). New §6.7 cross-references the new clickup-structure-sync working rule. Driver: live UI change made 2026-06-13; SOP lagged 24h until caught by screenshot comparison (tracking ticket 86aj1aaz6).Symphony Core Systems Team