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.

Workflows — the flows you actually run

The other sections are the reference. This one is the map: each workflow is a real situation you land in, what you do, and exactly what changes in Monday and in Jira as a result. If you only read one part of this guide, read this one.

Every workflow assumes you're signed into the console. Throughout, one rule everything rests on: after a board is built, the board is the source of truth, and only you change it.

Workflow 1 · “I have a rough spreadsheet”

You're picking up a new customer and all you have is a loose plan — an old Monday export, a sales handoff, a half-filled sheet. The columns are wrong, the durations are guesses, nothing is in our format.

What you do

1. Under Prepare a rough sheet, upload your loose .xlsx and click Prepare.
2. Download the normalized template and open the punch-list beside it.
3. Work the punch-list. Prepare fills what it's confident about (Task IDs, durations from dates, owner roles from the roster, blocks, a dependency spine) and flags the rest — fix the flagged cells with the drop-downs.
4. Set the two things Prepare can't guess: the Assignee email for any dev task that should land on a specific person (e.g. sholom@ficx.com), and the External Owner for any task a client-side person owns.
5. When the punch-list is clear, go to Build a new board (Workflow 2).

In Monday / In Jira: nothing yet. Prepare only converts a file — it creates nothing in either system. You end holding a clean, valid sheet, exactly where Workflow 2 starts. You never hand-format a messy plan: Prepare does the mechanical 80%, you confirm the 20% that needs judgment.

Workflow 2 · “I have a clean spreadsheet”

You have a filled, valid sheet — from Prepare or the blank template. Time to stand the project up.

What you do

1. In Build a new board, choose the filled .xlsx.
2. Pick the kickoff date (a weekend nudges to the next business day).
3. Type the customer name — it becomes the Jira component that walls off this customer's tickets, and the board name. Keep it exact; you'll reuse it.
4. Review & build, check the echoed summary, then Confirm & build. Wait a couple of minutes with the tab open for the Open in Monday link.

In Monday. A new board, named for the customer. Every task sits in its block (B1–B7), dependencies are drawn as real links, and the whole timeline is computed: each task gets a start, end, Slack (days), and a Critical Path flag, with the critical path highlighted on the Gantt. You authored no dates.

In Jira. For every Tool of Record = Jira task, a ticket in the shared CCL project tagged with this customer's component, carrying the task's name, description, and schedule dates (Start + Due), and assigned to the person from the Assignee column (or the default owner if blank). The clickable Jira key is written back onto each row. Monday-tool tasks get no ticket.

Workflow 3 · “I need to add a task to a live board”

The board is running and a task was missed, or scope grew. You need to add it without breaking the schedule.

What you do

1. Select the board, click + Add a task.
2. Fill the form — name, block, owner role, side, tool of record, scope, duration, and pick predecessors from the Depends On list. Set the Assignee from the live person-picker for a dev task, and an External Owner if a client-side person owns it.
3. Submit. It validates everything first (vocab, dependencies, no cycles, milestone rules) and refuses with a clear message before writing anything.

In Monday. The task drops into its block with a fresh, never-reused Task ID, and the schedule recomputes across the board: the new task and anything downstream move, untouched branches stay, and go-live shifts only if the task lands on the critical path (if it has slack, go-live holds).

In Jira. If it's a Jira task, one ticket is created (assigned, componented, dates + key written back). Existing tickets are untouched except their dates, which update to the recomputed schedule. Nothing is duplicated. Use the form, not a hand-edit — it can't produce a malformed task.

Workflow 4 · “A developer logged a delay in Jira”

A dev moves their ticket's Due date out, fills the Delay Reason, and leaves a comment. Their work will land late. You decide what that means for the plan.

What you do

1. Select the board, click Review & apply sync.
2. Read the per-ticket review: the date diff, delay reason, comment, status, and the projected go-live shift if you approve it — all computed without touching the board.
3. Decide per ticket. Approve what you accept; hold anything you want to call the developer about first.
4. Click Apply approved & recompute.

In Monday. Nothing moves until you approve — a developer's Jira date is a proposal, not a fact, which is what keeps you the sole editor and the board coherent. On apply, each approved ticket's delay is absorbed into that task's duration, the delay reason and comment land on the board, and the schedule recomputes once. A delay inside the task's slack does not move go-live; one on the critical path pushes it out. A held ticket changes nothing.

In Jira. After the recompute, the updated dates are pushed back to the approved tickets so both systems stay in step; their status, delay reason, and comments now mirror onto the board. Held tickets are left alone.

Workflow 5 · “Something changed on my side of the plan”

Not a dev delay — a change you own. A task will take longer, a dependency was wrong, or the customer added a step.

What you do

1. Make the change on the board: edit a Duration, fix a Depends On, or add a task via + Add a task.
2. Select the board, click Re-run.

In Monday. Re-run reads the board back, re-validates, and recomputes the full schedule. Only what changed moves; untouched branches keep their dates; the critical path, go-live, and slack update. On an unchanged board Re-run does nothing, so it's always safe.

In Jira. Any new Jira task gets a ticket (assigned, componented, key written back); existing tickets aren't duplicated, and their schedule dates update to the recomputed timeline. Re-run never re-edits a ticket's content beyond its dates. This is the everyday loop: change the board, Re-run, both systems catch up.

Workflow 6 · “I ran a smoke test and want to wipe it”

You built a demo or test board to try something, and now it's polluting Jira with throwaway tickets. You want it gone from everywhere.

What you do

1. Select the test board, click Delete customer data….
2. Read the warning, then type the exact board name to arm the red Permanently delete button, and confirm.

In Monday. The board is deleted.

In Jira. Every ticket for that customer's component in CCL is deleted, then the component itself. Order is tickets → component → board, so a mid-way failure leaves the board for a retry. Deleting a board directly in Monday would orphan its Jira tickets; this action purges both at once. Use it after every showcase to keep production Jira clean.

Workflow 7 · “I'm prepping for a weekly customer status meeting”

The regular check-in, and you need to show where the implementation stands and what's at risk.

This one is read-only and lives in Monday, not the console. Open the board and switch to the Gantt / Timeline view. The highlighted critical path is your talking track — those are the tasks that move go-live if they slip; tasks with slack have breathing room; the go-live milestone anchors the conversation. Because every dev delay (Workflow 4) and your own change (Workflow 5) is already reflected, the date you show is current, not a stale estimate. Group by Side to separate what Callvu owns from what the customer owes, and the External Owner field tells you exactly who to chase on client-side dependencies — the most common cause of slips. No console action needed; the value is that everything the console keeps in sync is now a live picture you can present without assembling anything by hand.

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. Or use the guided Add a task form below, which is the recommended path.

Add a task guided

Click + Add a task to add one task to the selected board through a validated form — the safe way to change the board. It auto-assigns the next Task ID (never reused) and validates exactly like the sheet — controlled vocab, dependency resolution, cycle detection, the milestone zero-duration rule — and fails loudly before writing anything. Depends On is a picker of the board's existing tasks; Assignee is a live person-picker of assignable Jira users (the ticket lands on that person); External Owner captures a client-side owner (name + optional email) for display. On submit it writes the row, recomputes the schedule, and — if Tool of Record = Jira — creates the ticket with the chosen assignee. Hand-editing the board and running Re-run still works; the form is the guided, guaranteed-valid path.

Delete customer data danger

Click Delete customer data… to permanently remove a test or retired customer from both systems: the Monday board and every Jira ticket plus the component in project CCL. It is type-to-confirm — you must type the exact board name to arm the red Permanently delete button — behind a warning that this cannot be undone. Order is Jira tickets → component → Monday board, so a mid-way failure leaves the board for a retry. Use it to keep production Jira clean after showcases.

Review & apply sync approve Jira changes

Click Review & apply sync to see what developers changed in Jira — a proposed new finish date (from the ticket's Due date), delay reason, comment, and status — before any of it touches the board. For each changed ticket you get a diff and the projected go-live shift if you approve it. Nothing is written until you approve. You approve or hold each ticket; a held ticket stays exactly as it was. When you click Apply approved & recompute, the console applies the approved tickets and runs one schedule recompute — this is how a developer's slip finally moves the go-live. See section 8 for the model.

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.

Review then apply — the approval gate

Schedule is Monday-owned, so a developer's Jira date is a proposal, not a fact, until you approve it. Review & apply sync reads every ticket for the board, and for each one that changed it shows the diff and the projected go-live shift if approved — computed without writing anything.

• Nothing touches Monday until you approve. You approve or hold each ticket individually.
• Approval is whole-ticket. Approving applies that ticket's new date (as a duration change), delay reason, comment, and status together — a ticket is never half-applied. A held ticket stays entirely in its prior state, so you can call the developer first.
• One recompute at the end. After you apply the approved set, the console runs a single CPM recompute (timeline, slack, critical path, go-live) and pushes the updated dates back to Jira so both systems stay in step.

How a date becomes a schedule change: the delay is the business-day gap between Monday's current finish and the developer's proposed Jira Due date; approving adds that to the task's Duration, then the recompute propagates it. A delay that fits inside a task's slack does not move go-live; a delay on the critical path does.

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 pushes T4's Jira Due date out by 3 business days, fills the Delay Reason field, and adds a comment. You click Review & apply sync: T4 shows the date diff and "if approved: go-live 3 business days later", plus the delay reason and comment. You approve T4 (or hold it to call the dev first). On approve, T4's Duration absorbs the 3 days, the schedule recomputes, the go-live moves, and the new dates are pushed back to Jira. A held ticket changes nothing. Re-running the review with no further Jira changes shows nothing to approve.

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 directly in Monday does not delete its Jira tickets — they remain in CCL under the component. To purge both systems, use Delete customer data in the console (type-to-confirm).

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