CPCana Admin Guide

This guide covers everything an Admin can do in the church task manager that a regular member or manager cannot, plus the org-wide features admins are typically responsible for setting up (users, teams, projects, workflows).

Only Admin/Manager see Dashboard and Teams in the sidebar. Only Admin sees User Management, All Trash, and Workflows.

1. Sign up at /sign-up. The very first account created on the org becomes Admin automatically — there is no separate "make me admin" step.
2. Go to User Management (/admin/users) and create an account for each staff member. You can set their role (Admin / Manager / User) and reset a password here at any time.
3. Go to Org Chart (/org-chart) and Teams (/teams) to build out the reporting structure (see §2 below).
4. Create your first project from All Projects (/projects) and add its members.

Create, edit, and delete user accounts; change any user's role; reset a password. This is the only place accounts are created. /sign-up only works for the very first account; after that it says sign-up is closed.

• Bulk CSV Import: Click "Import CSV" (columns: Name, Email, Role, and an optional Password; Download sample template gives you the layout). Rows with no password get a generated temporary password, shown on screen and in Download Credentials CSV. Managers are set afterward on the Org Chart. Imports are capped at 100 rows per batch (MAX_CSV_IMPORT_ROWS), and each import has an 8.5-second budget for creating accounts and sending welcome emails. Rows that don't fit are skipped, not created; re-upload the same file to pick them up, since already-registered users are skipped automatically. Accounts whose email didn't send still show their setup link on screen.
• Password Resets: Admins can trigger reset emails or copy a direct 24-hour setup link for users. Self-service reset is available at /forgot-password, rate-limited to 3 attempts per hour per email address to protect against enumeration attacks. Invites and resets never transmit plaintext passwords over email.

• Admins see every team in the org and can create new ones ("+ New team": name + a manager picked from a dropdown).
• Admins can change a team's manager at any time, delete a team, and add/remove/move members between teams.
• Managers only see teams they manage. They can add and remove members of those teams, and move a member from one of their teams to any other team. They can't create or delete teams or change a team's manager.

Renders a collapsible reporting tree based on each person's manager. Only Admins see the Change manager control on each person's card (the dropdown excludes that person's own reports, so you can't accidentally create a management cycle). Anyone without a manager and without reports shows up in a "Not yet placed" section below the chart — check this after adding new users.

Create a project from All Projects (/projects). Each project has its own header bar with links to the features below — these live on the project page itself, not in the main sidebar.

Only Admins add people to a project: + Add member opens Add a member, which searches staff accounts by name or email. Click a member's chip (+ Make Manager / ✓ Manager) to flag them as that project's manager. That flag does one thing: a Manager-role person flagged this way gets the project in their digest's Project Summary (a User-role person gets nothing from it, and Admins get every project). Guests (people without accounts) are handled differently — see §7.

Every project has six tabs:

• List — the classic task list. This is also the only view that shows Custom Fields as columns.
• Board — status-column board.
• Timeline — tasks laid out by date.
• Grid — spreadsheet-style bulk editing (see §4).
• Workload — open work per person.
• Dashboard — project-scoped stats (separate from the org-wide Dashboard in §6).

"Manage fields" on the project header. Field types: Text, Number, Date, Dropdown (comma-separated options, extendable later), Checkbox. Deleting a field warns that its values will be lost. Any project member can manage fields — this isn't admin-gated, but as the admin you'll typically be the one setting up a project's field schema before handing it to a team.

"Manage tags" on the project header. Create a tag with a name and a color from a fixed palette; rename and recolor inline; deleting a tag removes it from every task that had it. Tags are then assignable from a task's detail panel or from the Grid view's Tags column.

Per-project "when this, then that" rules, shown as flow cards (trigger → action) or a compact list (e.g. "When 'Set up chairs': status becomes Done → Set status to In Progress on 'Clean up'"). Each rule has an Enabled switch, Delete, a run history (total count plus the latest five runs), and a Check rule button.

"+ New rule" lets you configure:

• When… — pick a source task, and a trigger: Status changes to… / Assignee changes / Due date is approaching (with a "days before" input).
• Then… — pick an action: Set status, Set assignee (a specific person, or "same as source"), Move to section, or Create a new task (with its own title/description/priority/assignee). The target task can be another task or "the source task itself".
• Quick Recipes fill in the form for four common patterns; they never choose tasks or sections for you.

Guards: CPCana rejects a rule that changes what it watches on the same task (e.g. "when this becomes Done, set it to To Do"), and a Move to section whose section is in a different project from the task being moved.

Check rule reads the rule's setup and its tasks' current state and reports what the engine would do, including why it would skip (trashed task, missing due date, nothing to assign). It never runs the rule. Rules that can't run show a Won't run badge. Print runbook prints a review sheet of all the project's rules with check-off boxes and a sign-off block.

Due-date-approaching rules are checked once a day by a background job — expect up to a day of lag, not real-time firing. They skip a source task that's already Done or in the trash.

Public, no-login forms that create a task in a fixed project/section when submitted — useful for "request a room setup" or "submit a bulletin item" type requests.

"+ New form": a name (the /forms/… address is made from it), a description, the section new tasks land in (New submissions go to), and a default assignee. Each form lets you add fields (label, type — Text/Paragraph/Email/Date/Dropdown — required checkbox, and options for Dropdown fields). Each form's card has an Accepting submissions switch and a Copy link button for the public URL. Deleting a form also deletes its submission records; the tasks it created stay, with each submission's answers in the task description.

Reached from the project's Workflows & Automations button, which opens a two-tab page: Process stages (this) and Automation rules (above). Lets a project apply one of the org's process blueprints (see §5), which adds the blueprint's stages/tasks to the project's sections in one click. The page shows the project's sections as stage cards (or a compact table) with each task's status, priority, and assignee.

• Check stages flags any stage with no tasks and shows overall progress. It doesn't change anything.
• Runbook notes is a saved notes box for the printout. Generate summary fills it with a plain-text summary of the project's setup (members, sections, custom fields, tags, automation rules); it's assembled from project data, not written by AI.
• Print runbook prints the stages and tasks as a checklist with check-off boxes, the notes (if included), and a sign-off block.

Grid view is a spreadsheet for a project's tasks — Title, Tags, Assignee, Priority, Status, Due Date, and a read-only Repeat summary column.

• Select: click a cell, or drag/Shift-click to select a range.
• Arrow keys move focus; Shift+Arrow extends the selection; Tab / Shift+Tab move across.
• Enter edits the focused cell; typing directly over a focused Title cell replaces its text.
• Copy (⌘/Ctrl+C) and Paste (⌘/Ctrl+V) work like a spreadsheet — paste a block of tab/newline-separated values across the same shape of cells. Pasting past the last row creates new tasks automatically.
• Fill-down (⌘/Ctrl+D) copies the top row of your selection down through the rest of it.
• Undo (⌘/Ctrl+Z) steps back through your last 20 grid edits, single cells or bulk. Undoing a paste that added rows removes them.
• The Repeat column can't be set by paste or fill-down — use This task repeats in the task's detail panel (§8) for that.

Any project member can use Grid view, not just admins — but it's the fastest way for an admin to clean up or reassign a large batch of tasks in one pass.

This is different from a project's "Process stages" tab (§3) — this is where you build the reusable process blueprints that projects pull from. The page has two tabs:

• Process Blueprints. "+ New blueprint" — start blank, or copy an existing template as a starting point. Each card shows its team, stage count, and task count; click to expand the builder and add Stages → Tasks → Subtasks (title, description, default priority — one level of subtasks only). Any blueprint can be applied to a project. Marking one as a Template makes it available to copy when creating a new blueprint and lists it first when applying one to a project.
• Cross-Module Routing. Choose the operations project where Inventory and XP Hub tasks land (its Base To Do section), and who gets each kind: restock tasks (one "Restock Needed" task per room, such as "Restock Needed: Main Building / Kitchen", when a stock count leaves items below par; it lists every below-par item in that room, and an open one is updated rather than duplicated), delivery tasks (a "Distribute Order" task when a restock order is marked received), and board packet print tasks (from XP Hub print requests). Only the chosen project's members and admins can be picked, so whoever you choose can open the task; they get the usual assignment notification. Until a project is chosen, Inventory creates no tasks, and print requests fall back to the first shared project named like Administration, Operations, or Staff (or failing that, the first shared project), unassigned.

Typical use: build a "New Member Onboarding" or "Event Planning" workflow once, then every project of that type applies it instead of re-creating the same task structure by hand.

Org-wide (Admin) or team-scoped (Manager) overview. If a Manager doesn't yet manage any team, they see an empty state pointing at Teams.

• Top stat tiles: Total Users (Admin) / Team Members (Manager), Open Tasks, Overdue, Due Next 7 Days, Completed (last 14 days). Clicking a task metric tile anchor-jumps directly to the corresponding task list below.
• Admin-only extra row: Teams count (links to /teams), Projects count (links to /projects), Unassigned Tasks count.
• Charts/tables: Tasks by Status, Open Tasks by Priority, a "Workload by Team Member" table (open/overdue/due-soon/completed/completion-rate per person), a Teams table, a Projects table (click through to any project).
• Task lists: Four operational lists capped at 10 items each (displaying a "Showing 10 of N" count when capped) — Overdue, Due in the Next 7 Days, Open Tasks, and Recently Completed (last 14 days). Clicking any task title opens its detail modal directly.

Admins see the entire org here. Managers see the tasks assigned to members of the teams they manage, across every shared project. The meetup, inventory, volunteer, and XP panels at the top aren't team-scoped; everyone who can open the Dashboard sees the same ones.

There's no email invite for guests — it's a copy-a-link flow, scoped to a single task:

1. Open any task's detail panel and click "🔗 Share with guest".
2. Click "+ New guest link" to generate a link. Copy it and send it however you like (email, text).
3. The guest opens the link (/guest/[token]) with no login and sees the task's title, description, status, priority, due date, and comment thread, and can post a comment (kept separate from staff comments).
4. Links don't expire. To shut one off, click Revoke in the same panel; it stops working immediately.

Any member of the task's project can create or revoke its guest links; Admins can on any task. Managers get no extra reach here. This is different from + Add member on a project, which adds an existing staff account to the project — use guest links for outside parties who shouldn't have an account.

There's no separate recurrence page — open any top-level task's detail panel (subtasks can't repeat) and check "This task repeats" to reveal the Repeat editor:

• Frequency: Day / Week / Month / Year, with an interval (e.g. every 2 weeks).
• Repeat style:
  • "Reset on a schedule" — every repeat day the task goes back to To Do with the next due date, whether or not it was finished. Good for things like "set up chairs" that happen on a calendar regardless of history.
  • "Reset after it's done" — the task goes back to To Do one interval after it's marked Done. Good for things like "replace HVAC filter," where the next round shouldn't start until the current one is actually finished.
• Next reset (optional): the date of the next reset, if an upcoming cycle needs to move.
• Ends on (optional): stop resetting after a date.

A repeating task is one card that resets in place overnight (around 1–2 AM Central) — it moves back to the project's base To Do column, its subtasks are unchecked, and its due date rolls forward. No copies are created. Grid view shows a read-only summary of a task's recurrence in its Repeat column.

• Trash (/trash, everyone): tasks you personally deleted. Restore or permanently delete.
• All Trash (/admin/trash, Admin only): every deleted task from every project and every user. Every restore from All Trash asks you to confirm, and the prompt names who deleted the task.

Deleted tasks are permanently purged 30 days after deletion. Trash shows how long each item has left; All Trash doesn't, so check the deletion date. Deleting a whole project skips the trash entirely and is permanent. Permanently deleting a task also removes its comments, subtasks, custom field values, and reminders — there's no undo past that point.

• Calendar (/calendar, everyone): a month view of tasks by due date (plus finalized meetups shared with you), filterable by status/priority/assignee/team/project/tag. Admins see tasks across every project; others see only their own projects.
• Calendar connections (/settings/integrations, per-user): Connect/Disconnect cards for Google Calendar and Outlook. Note: connecting only stores the account link today — there is no live sync or import/export yet, and the panel says so explicitly. Tasks can't be exported to a calendar file, and nothing imports one; the one exception is a finalized meetup, whose Add to Calendar menu offers Google, Outlook, Microsoft 365, and a downloadable .ics file.
• Public API (/api/v1/...): authenticated with a personal API key from /settings/developer. An Admin's key can read every task in the org; anyone else's key is limited to their own projects.
• Webhooks (/settings/developer): register a URL and pick which events to receive (task created/updated/completed/deleted, comment added). Deliveries are signed (X-Webhook-Signature) so your endpoint can verify they came from this app.

Press ⌘/Ctrl+K anywhere in the app to open global search (2+ characters). Results are grouped into Tasks, Comments (a line of the comment and the task it's on; click to open the task), Projects, People & Ministry Teams, Navigation Pages, and (when those modules are on) Meetups, Inventory, RACI charts, and Discernment Frameworks. You only ever see tasks and comments from projects you can open. The Navigation Pages results respect your role, so an Admin can search-navigate straight to "User Management," but a regular member won't see admin-only pages in their results.

When the deployment has a handbook library (NEXT_PUBLIC_HANDBOOKS_URL, see §12), a Handbooks group lists the guides a search asks for: all of them for handbook, guide, manual, help, or docs, and otherwise the ones it names, such as admin, training, field card, or runbook. They open in a new tab. Everyone sees them whatever their role, since the library is public. With the search box empty, Handbooks & Guides is one of the quick shortcuts.

There's no separate "org settings" area — each person, including admins, configures their own preferences:

• Notifications: per-notification-type email toggles, plus overall digest frequency (Off/Daily/Weekly) and your preferred hour to receive it.
• Integrations: the Google/Outlook calendar connect cards described in §10.
• Developer: manage your personal API keys (shown once at creation — copy it immediately) and webhooks. Admins also see Outbound Email & SMTP here: whether email is configured, the sending address, setup warnings, and a Send Test button that checks the connection and sends a test message. It keeps no delivery history.
• Navigation: drag to reorder, and check/uncheck to show or hide items in your own sidebar. This only changes what's visible to you — it doesn't change what any other user, or any role, is allowed to see.
• Help & Handbooks: a card for each handbook in the CPCana Handbooks Library, with who it's for and a Read handbook button that opens it in a new tab. It appears only when the deployment sets NEXT_PUBLIC_HANDBOOKS_URL to its library. The same setting shows Handbooks & Guides above Settings in the sidebar, the Handbooks results in search, and the guide links on individual pages: Field Guide on a project's Workflows & Automations page, Field Card on Child Protection and Onboarding, and the Admin Guide link on User Management and Workflows. Unset, all of them are hidden.

Operations at a physical church frequently transition from digital planning to paper clipboard sheets for volunteers, kitchen workers, and setup crews:

• Inventory Restock Orders (/inventory/orders/[id]):
  • Click "Print Packing Slip" on any purchase order to produce a clean physical receiving manifest.
  • Automatically suppresses navigation bars, buttons, and status controls.
  • Displays church purchase order header, item quantities, location/par levels, pen check-off boxes, and a receiver sign-off block.
• Volunteer & Potluck Rosters (/meetups/[id]):
  • Click "Print Check-in Sheet" in the Meeting Roster card.
  • Formats a physical clipboard sign-in sheet for the church foyer or fellowship hall.
  • Displays check-off boxes for confirmed volunteers plus blank standby / walk-in lines ([ ] _______________________ (Walk-in / Standby)) for spontaneous helpers.
  • Includes a Check-in Lead signature and date verification block at the bottom.

All modals and slide-overs follow the WAI-ARIA modal dialog pattern through useModalA11y (the few yes/no prompts that use the browser's own confirm box are accessible by default):

• Focus Trapping: Pressing Tab or Shift+Tab cycles keyboard focus exclusively within the active dialog, preventing focus from escaping to obscured background controls.
• Escape Dismissal: Pressing Escape dismisses open dialogs without submitting unconfirmed data.
• Focus Restoration: When a modal closes, keyboard focus automatically returns to the button or trigger element that opened it.
• Semantics: Modals carry accessible role="dialog", aria-modal="true", and aria-labelledby headings for screen readers.

The Communications module plans and schedules cross-channel church announcements (Sunday announcements, website, app, social media, email, signs, bulletin boards, and pulse print). Administrators and Managers configure the module at Communications > Settings (/communications/settings).

The module is activated through the ENABLED_MODULES environment variable:

• Include the 'communications' key (e.g., ENABLED_MODULES="inventory,meetups,communications" or ENABLED_MODULES="all").
• When omitted or unset, all /communications screens and /request-announcement return 404.

Under Project for Communications tasks, select a shared project from the dropdown:

• All generated communications tasks (reviewing requests, making graphics, writing descriptions, review, and channel publish tasks) land in this project's base section.
• Mandatory guard: A project must be chosen. Request approval and task creation are refused without one (Choose a project for Communications tasks in Communications → Settings first).
• Project membership: Staff and volunteers must be members of the chosen project to be assigned communications tasks.

Communications workflows are divided into five pipeline roles:

• One person, multiple roles: One team member can hold several roles (or all five).
• Assigning a person: In each role's card, choose a registered user from the Assign person dropdown (or select Nobody to clear the assignment).

When a role is assigned to someone else:

• Only open tasks move: Only the previous holder's open tasks of that specific role's step move to the new assignee. Filling an empty role moves that role's fallback or unassigned open tasks to the new holder.
• Finished tasks stay: Any tasks already marked Done remain with whoever completed them, preserving the audit history.
• Clearing a role moves nothing: Setting a role to Nobody leaves open tasks where they are; nothing moves.
• Non-members are skipped: If the new role holder is not a member of the Communications project (and not an administrator), tasks they cannot access will not transfer to them (Moved X of Y open tasks. The rest stayed because the new person is not a member of the Communications project).
• Confirmation dialog: If open tasks will move, a confirmation modal confirms: "Move open tasks: [X] open tasks will move from [Old Name] to [New Name]. Finished tasks stay with whoever did them." Bulk reassignment sends no individual task notifications.

If a role is set to Nobody, or if the assigned person cannot access the Communications project:

• Newly generated tasks for that step fall back automatically to the Coordinator.
• If the Coordinator is also unassigned (or not in the project), tasks land Unassigned.

Lead times configure due dates relative to an announcement's earliest channel due date. The Graphic, Copy and Review tasks happen once per announcement; each channel due date is its own publish task.

• Graphic and description due: Days before the earliest channel due date (default: 14 days, range 0–120).
• Review due: Days before the earliest channel due date (default: 10 days, range 0–120; clamped so review is never due before production).
• Create publish tasks: Days ahead to generate channel publish tasks (default: 14 days, range 1–60). Tasks inside this window are created immediately when an announcement is approved; tasks further out are created each morning by the daily background sweep as they enter the window.
• Past dates guard: Dates in the past are never assigned. If an announcement is approved close to its event, production due dates clamp to today. Once a Graphic, Copy or Review task exists and goes overdue, it keeps its due date (it shows as overdue) instead of moving to today.
• Channel due dates: When someone ticks a channel, the date fills in from that channel's standard lead (Sunday announcements: the Sunday before the event; Website, App, Bulletin board, Pulse: 14 days before; Sign: 13; Social media: 7; Email: the Friday before). These standard leads are built into CPCana, not settings.

Add several (/communications/bulk) adds up to 50 announcements in one go, each with its ticked channels on their standard due dates. Nothing is added unless every row is valid. Each person gets one notification saying how many Communications tasks they were assigned, instead of one per task. If a big batch runs past about 8 seconds, the rest of its tasks are made by the next daily run (the page says so).

Each announcement holds one Google Drive link to its graphic; CPCana stores no image files. Only https://drive.google.com and https://docs.google.com links are accepted. Graphics uploaded before 2026-10-08 still open, and replacing or removing one deletes the old file from storage.

The Public Announcement Request Link card displays the URL (/request-announcement) with a Copy button. Share this link with ministry leaders and volunteers so they can request announcements without logging in.

Only the Coordinator, managers, and administrators can use From eSpace file on Add several, apply eSpace changes, or open the review page (/communications/espace-changes). Other Communications role holders can't add rows linked to eSpace. When an import records changes, those same people see a banner in Communications with the number of changes to review and the "Last full eSpace import" date, and each gets an in-app notification (whoever ran the import is not notified). The notification type is labelled "eSpace calendar changes" in each person's notification preferences, where its email can be turned off.

Anyone can save personal views on the Announcements page (up to 30 each). Only the Coordinator, managers and administrators can share a view with everyone, and they can change or delete any shared view; everyone else can change and delete only their own.

• Reminders and digests run once-daily (send-reminders at 15:00 UTC, digest at 14:00 UTC). The Vercel Hobby plan rejects crons scheduled more frequently than once a day, so scheduled afternoon reminders arrive the following morning.
• Module activation (ENABLED_MODULES): Add-on modules (inventory, meetups, raci, xp, child_protection, onboarding, communications) are hidden unless ENABLED_MODULES is set in the deployment environment. An unset or blank variable enables no modules; prefer setting ENABLED_MODULES="all" to show all features.
• Child-protection renewal tasks come from a weekly sweep (Mondays, 09:00 UTC) that files one unassigned review task per lapsed or expiring person, at most once every 30 days. They land in the project named by the CHILD_PROTECTION_CRON_PROJECT_ID environment variable (first section, unless CHILD_PROTECTION_CRON_SECTION_ID names another). If the project variable is unset, or the child_protection module isn't enabled, the sweep files nothing. Make sure someone watches that project and assigns the tasks.
• Push and SMS reminders aren't implemented — reminder emails only, by design for now.
• Calendar sync is inert — connecting Google/Outlook Calendar stores the connection but doesn't actually import or export events yet.
• No task calendar export or ICS import. Only finalized meetups offer an .ics download (Add to Calendar).
• Automation and repeat timing has some lag: due-date-approaching automations and repeating-task resets run in once-daily background jobs, not instantly — expect them within a day, not the second a condition is met.
• Communications repeating events: A repeating event's channel due dates are whatever you set; they don't follow each occurrence.
• One graphic link per announcement: Announcements hold a single Google Drive link to the shared master graphic; channel-specific sizes or variants are not stored.
• No calendar overlay beyond tasks: Communications placements appear on the calendar view only as their generated CPCana tasks, not as a distinct communications calendar layer or external calendar feed.
• Communications project requirement: The communications module requires an active shared project configured in /communications/settings. Approving requests and creating tasks are blocked until one is chosen.