Back to Blog
Product UpdateDelivery HubGantt0.184

Drag-to-Reschedule for Salesforce Delivery Teams

GB
Glen Bradford
7 min read

Salesforce is good at record integrity and bad at planning. That's why most delivery teams end up maintaining two systems — the Salesforce org where the work actually lives, and a Jira or Asana board where they try to see it on a timeline. Every week, the two drift apart.

Delivery Hub 0.184 is the release where that stops. Drag a bar on the Gantt, the dates save to Salesforce. Review a week of edits before they commit. Script a reschedule from the browser console. One system. No drift.

4 → 1
Clicks per Reschedule
3
Mount Surfaces
11
Console API Verbs
$0
Per-Seat Cost

The Problem You Already Know

A work item slips. The PM opens the Salesforce record. Clicks edit. Changes the end date. Tabs through two other fields she didn't mean to touch. Clicks save. Opens the next record. Repeats.

Or — more commonly — she opens Jira, where her team already lives because the Salesforce UI is too slow. The Jira board has the drag. Salesforce still holds the contract data, the approvals, the invoicing. Two systems, two sources of truth, one weekly sync meeting that exists to explain the drift.

Delivery Hub's Gantt has shown Salesforce records on a timeline for a while. What it didn't do was let her move them. That's the gap 0.184 closes.

What 0.184 Ships

1. Drag-to-reschedule on real Salesforce records

Grab a bar. Drag it. The dates persist to the WorkItem__c record immediately, through the same Apex methods a manual edit uses. If Apex rejects the save (validation rule, sharing rule, anything), the bar snaps back and the user sees the reason. No silent dropped writes.

Drag the left edge to move just the start date. Right edge to move just the end. Drag the middle of the bar to keep the duration and shift both. Drag a bar between priority lanes to re-bucket. All optimistic — the UI updates immediately, the Apex call happens in the background, the UI reverts if the server disagrees.

2. Preview before commit

For teams that prefer batch-edit mode — move 20 bars during a planning meeting, then commit once at the end — 0.184 ships the preview modal. Every pending change is listed with a human-readable diff (“start: April 22 → April 29”, “priority: planned → active”, “parent: cleared”). Cancel reverts the whole batch. Confirm writes it all through.

The preview is live on the cloudnimbusllc.com planning view today. The Salesforce-side activation ships with the 0.185 batch-commit cut, a few days out. The feature flag is already in the library, so that release is a configuration change, not a library rebuild.

3. A console API for scripting

Open DevTools on any page running the Gantt. Type window.__cnEdit.help(). Eleven verbs print with one-line docs — moveTask, moveToGroup, reorder, setParent, editItem, submit, reset, getState, and a few others. Every verb calls the same Apex path a drag uses. Nothing new on the server.

We'll come back to why this matters in a minute.

Same Gantt, Two Homes

The Delivery Hub Gantt renders identically in three different mount paths: an embedded Lightning Web Component inside a record page, a standalone FlexiPage for a fullscreen view, and a Visualforce + Lightning Out surface that strips the Salesforce chrome entirely for demos and external sharing. One library, one IIFE bundle, three ways to host it.

The same bundle also powers the public planning view on cloudnimbusllc.com, where customers and partners who don't have Salesforce seats can review the same timeline without a license. Partners get a read-friendly board; admins get the full edit-and-commit loop. When both sides edit, Salesforce stays the system of record — the web view treats it as the source of truth.

Why it matters

Your planning tool follows your user. Internal admin on Salesforce, partner on the public web, operations dashboard embedded in a third-party page — same Gantt, same data, same edit surface. You don't maintain three forks; you maintain one.

The Scripting Story

Back to window.__cnEdit. On mount, the Gantt prints a banner:

[cn-edit v0.1.0] editable timeline ready.
Drag bars or call window.__cnEdit.help() for the programmatic API.

An admin who learned the API on the public web can sit in front of a Salesforce org and script a mass reprioritization with the same commands. An ops lead running a weekly planning meeting can paste a saved sequence of moveTask calls to fast-forward a plan. A test harness uses the same verbs to assert that a drag lands the right way.

Most interestingly — an AI agent with browser access drives it the same way a human does. Paste a natural-language ticket into the console, the agent reads the board state via getState(), decides a reschedule, calls moveTask(‘a0x…’, ‘2026-04-22’, ‘2026-04-29’), and the bar moves. No new integration surface. No API key to provision. Just the same verbs the drag affordance already exercises.

The debug affordance became a feature affordance. We built the console bridge to accelerate our own testing; it turned into a customer-facing primitive.

Audit-Grade Change Tracking (In Flight)

Every enterprise delivery team has the same audit question: who moved this, and why? Today the answer usually lives in a Jira history tab, a stale status email, or nowhere at all.

We're closing that gap in three steps across three releases:

  • 0.184Preview before commit. Every pending change is listed in a modal before a batch commits. The dialog you'd want your team to see before a planning change goes live.
  • 0.185Batch commit. Buffer twenty edits during a planning meeting. Review the diff. Commit once — the full batch lands as one Apex transaction. Cancel drops the whole buffer.
  • 0.186Activity tab + change records. Every field change flows through Salesforce Field History Tracking. Every committed batch writes a WorkItem_Change__c record with the human-readable note and the list of items touched. “What did we agree to last Monday?” becomes a one-click answer.

Rollout and Safety

0.184 is a managed-package install. No schema migrations. No new objects. No new permissions to assign. The drag affordance routes through the existing updateWorkItem* Apex methods that your UI has been using for months — if your users can edit records today, they can drag today. No net-new surface to threat-model.

Rollback is the same managed-package version-downgrade flow you already use. If 0.184 misbehaves in your org, reinstall the prior version and the library reverts. No migrations to undo.

What's Next

The next two releases are tightly scoped:

  • 0.185 batch commit. A few days out. Toggle batch-mode on any mount; the Submit button commits the whole pending set through one Apex call.
  • 0.186 Activity tab. An in-Gantt panel reading Salesforce Field History for the visible work items, plus a log of recent committed batches. The stakeholder question “what changed this week?” gets answered in the same view where the planning happens.
  • 0.190 cross-system sync. Longer-term: when the public planning view on cloudnimbusllc.com is the origin of an edit, the write flows back to Salesforce through a reviewed queue. For customers who want to expose planning access beyond Salesforce seats without losing audit trail.

Install 0.184

The managed package is free. It installs into any Salesforce org with standard Setup → Install a Package permissions. If you're already running an earlier Delivery Hub version, this is an in-place upgrade.

Engineering companion piece: the development arc behind this release — four-window agent orchestration, the silent-swallow bug that ate a day, and how a debug console bridge became a product feature — is written up on glenbradford.com.