User Guide

The CCL Implementation Console turns a filled task spreadsheet into a fully structured Monday board — typed columns, linked dependencies, a business-day schedule with critical path — and opens the Jira tickets that belong in Jira. It then keeps a defined set of Jira fields flowing back into Monday on demand. This guide covers every use case, every feature, how it works under the hood, the gotchas, and a full worked example.

1 · Getting started

Open the console and enter the access secret. That is the only credential you need — you do not need a Monday, Jira, or Vercel account. The secret unlocks the console; everything the console does uses shared service accounts behind the scenes.

The console has two jobs, shown as two cards:

• Build a new board — from a filled task sheet.
• Manage an existing board — Re-run (recompute) or Sync (pull Jira updates).

Before your first build, grab the blank sheet:

Download the blank task template ↓

The template has two tabs: Tasks (where you work) and Legend (the allowed values, for reference). The console only reads Tasks.

The finite-value columns — Group (Block), Type, Side, Tool of Record, Scope, and Status — have built-in Excel drop-downs: just pick a value and Excel blocks anything else. Owner Role is free text so you can pick more than one role (comma-separated) — its cell note lists the allowed values.

2 · The task sheet (data contract)

Parsing is header-based: columns are matched by name, so order does not matter and extra columns are ignored. Every row is one task and must have a Task ID. There are no section-header rows.

The sheet has 13 required columns:

*Duration may be blank for a milestone (treated as 0); for real tasks give a whole number of business days.

There are no Start Date or Due Date columns. You never author dates — the console computes the whole timeline from the kickoff date + durations + dependencies.

Allowed values (controlled vocabularies)

These columns only accept exact values. Anything else fails loudly at upload.

Group (Block) values

Use the code (recommended) or the exact block title — both resolve to the same block. Casing and punctuation are forgiving.

Choosing Tool of Record — Monday or Jira

On the implementation sheet, Tool of Record has exactly two values: Monday or Jira. It records where the truth of the task lives — not who works on it — and it is the deterministic switch that decides whether the console opens a Jira ticket.

Apply one question to every task: is this task cut as a dev ticket — engineering work a developer picks up and completes in the dev workflow?

Monday is the default. Everything is Monday unless it is dev-ticketed — no task is left unclassified.

Examples: “Build the payment micro-app workflow” → Jira (a dev builds it). “Confirm compliance sign-off on data handling” → Monday (a project gate, not a dev ticket). “Kickoff scoping call” → Monday. “Provision the customer tenant” → Monday, unless the dev team specifically tracks it as a Jira ticket — then Jira.

3 · Prepare a rough sheet (optional)

Already have a project plan — a Monday export, an old spreadsheet, a loosely-filled sheet? Prepare converts it into a template-formatted copy, best-effort, and hands you a checklist of what to fix by hand. It only converts a file — nothing is created in Monday or Jira.

1. On the console, under Prepare a rough sheet, choose your .xlsx and click Prepare.
2. You get a Download normalized template button and a punch-list of what to confirm or fill.
3. Open the downloaded sheet, fix the flagged items (using the drop-downs), then use Build below.

What it fills for you, best-effort:

Prepare is advisory: it fills what it's confident about and flags the rest. Work through the punch-list, confirm the flagged items, and you're ready to Build.

4 · Use case: create a new board (Build)

Use Build once per customer, at the start, to turn the filled sheet into a live board.

1. In Build a new board, choose your filled .xlsx.
2. Pick the Kickoff date — the project start. (A weekend date is nudged to the next business day.)
3. Type the Customer name. This becomes the Jira component that isolates this customer's tickets, and the board's name.
4. Click Review & build, confirm the echoed summary, then Confirm & build.
5. Wait — a full board takes a few minutes. Keep the tab open. You get an Open in Monday link and a summary.

Behind that one click, in order, the console:

1. Validates the whole sheet and reports every problem at once (nothing is created if validation fails).
2. Clones the template board (so every column already has the correct type) and names it after the customer.
3. Drops each task into its block group.
4. Links dependencies as native Monday links.
5. Computes the business-day schedule and writes each task's timeline, slack, and critical-path flag.
6. Creates a Jira ticket for every Tool of Record = Jira task, and writes the clickable Jira key back onto each row.

5 · Use case: manage an existing board

Pick a board in the Board dropdown (it lists every customer board in the workspace). Then:

Re-run recompute

Click Re-run after you add or edit tasks on the board — no re-upload. Re-run reads the board back, re-validates it, and runs the same pipeline as Build:

• Links only new dependencies; existing links are left alone.
• Recomputes the full schedule (forward + backward pass + slack). Affected tasks move; untouched branches keep their dates.
• Creates Jira tickets only for qualifying tasks that don't have one yet. It never duplicates and never updates existing tickets (pushing schedule changes to Jira is intentionally out of scope for now).

To add a task on the board: add an item in the right block group, fill its Task ID, Type, Duration, Tool of Record, and put predecessor Task IDs in the Depends On text column. Then Re-run.

Sync from Jira pull updates

Click Sync to pull the latest Jira dev fields onto the board for every item that has a Jira key. It is manual, on-demand, and safe to run repeatedly. See section 7 for exactly what it copies.

6 · All features

7 · How it works under the hood

Board structure

Every board is a clone of one template, so column types are guaranteed. Beyond the sheet fields, the console maintains: Timeline (start/end bar), Dependencies (native links), Slack (days), Critical Path, Jira Key (link), and the three Jira-owned fields. Blocks are Monday groups, not tasks.

Scheduling (business-day Critical Path Method)

The scheduler runs a full CPM in business days (weekends excluded, mid-task as well as at the ends):

• A task's finish = its start + Duration business days. (A 3-day task starting Friday finishes the following Wednesday.)
• A task with predecessors starts the next business day after its latest predecessor finishes — it waits for all of them.
• Milestones (Duration 0) land on the convergence date and consume no day, so they never push downstream work.
• Root tasks (no predecessors) start at kickoff.
• A backward pass gives each task its slack; zero-slack tasks form the critical path.

The schedule is a conservative calendar baseline, not a commitment. Holidays are not modelled (only weekends).

Jira model

• One shared project, CCL, holds every ticket. Per-customer separation is a Jira component named after the customer — created automatically on first Build and reused after.
• Trigger: a ticket is created when Tool of Record = Jira. (Owner Role does not trigger tickets — it is context only.)
• Field mapping: Name → Summary, Description → Description, and Task ID plus Owner Role / Side / Scope are attached as Jira labels for traceability.
• Idempotency: the console checks the Jira Key column. Empty → create the ticket and write the key back immediately. Present → skip. This is why Re-run never duplicates tickets.

8 · How syncing works (both directions)

To avoid an endless loop, every synced field has exactly one owning system and one direction. Task ID is the join key on both sides.

Sync is a full sweep and stateless: it looks at every board item with a Jira key, reads those three fields, and writes them to Monday — no "changed since" tracking to drift. It only writes fields that actually changed, so a Sync with no Jira changes reports zero writes. It is manual on purpose (a delay note does not need second-by-second freshness, and there are no silent background failures).

9 · A full worked example

Say you fill the Tasks tab like this for customer Acme Bank:

You upload it with a Monday kickoff and customer name Acme Bank. After Build:

• T1 (sign-off milestone) sits on the kickoff date. T2 and T3 both start the next business day (they depend on T1) and run in parallel.
• T4 waits for the later of T2 (5 days) and T3 (3 days) to finish, then runs 8 days. T5 (go-live gate) lands on T4's finish.
• The critical path is T1 → T2 → T4 → T5 (T3 has slack, because T2 is the longer of the two parallel tasks). Each row shows its Slack and Critical Path flag.
• Two Jira tickets are created — for T3 and T4 (the two Jira rows) — in project CCL under component Acme Bank. Their clickable keys appear in the Jira Key column.

Later, on the board, you add a UI task: a new item in B5b, Task ID T6, Type task, Tool of Record = Jira, Depends On T4, Duration 2. You click Re-run:

• The T6 → T4 dependency is linked (the only new link).
• T6 is scheduled after T4; T1–T5 keep their dates.
• One new Jira ticket is created — for T6. T3 and T4 already have keys, so they are skipped.

Then a developer moves T3's Jira ticket to In Progress, fills the Delay Reason field, and adds a comment. You click Sync: T3's row now shows Dev Status In Progress, the delay reason, and the recent comments. Running Sync again with no further Jira changes writes nothing.

10 · Gotchas

• Task IDs are permanent join keys. Never renumber or reuse one. Changing a Task ID breaks the link between the board item and its Jira ticket.
• The board — not the sheet — is the source of truth after Build. Edit on the board and Re-run. Editing the sheet and re-uploading makes a new board.
• Add dependencies in the Depends On text column (Task IDs), not the native Dependencies column. Re-run reads Depends On and creates the links from it.
• Tool of Record = Jira is the ticket trigger — not Owner Role, not Side. A task owned by Callvu Dev but with Tool of Record = Monday gets no ticket.
• Milestones must have Duration 0. A gate or sign-off with a non-zero duration fails validation.
• Every Depends On must point to a real Task ID, and there can be no cycles (A→B→A). Both fail loudly.
• Controlled values are exact. Unknown Type / Side / Tool of Record / Scope / Status / Owner Role / Group values fail. Comma separates Owner Roles; slash is literal; merged block labels are rejected.
• Keep the customer name consistent. It is the Jira component and is stored on the board; Re-run and Sync read it from there.
• To force a ticket to be recreated, clear its Jira Key on the board, then Re-run. A present key always means "skip".
• The three Dev columns are overwritten by Sync. Don't hand-edit them in Monday.
• Kickoff is set once, at Build, and stored on the board; Re-run reuses it. A weekend kickoff snaps to the next business day.
• The schedule is a baseline, not a promise. It assumes work starts as early as dependencies allow and models weekends only (no holidays).
• Build runs for minutes on a full board. Keep the tab open until you see the board link or an error.
• Don't touch the template board. Every Build clones it; changing it changes future boards.
• Deleting a customer board in Monday does not delete its Jira tickets — they remain in CCL under the component.

11 · Troubleshooting errors

Errors are shown in full, in a red box, and nothing is created when validation fails — fix everything listed and try again.

Something not covered here? Note the exact error text and what you were doing, and reach out to the implementation team.

← Back to the console