Building client relationships into Chronicle

A client relationship should survive a change of project tool, payment provider or staff member. That principle shaped our work on Chronicle: give commercial facts a stable home, then connect the systems that use them.

We extended our Drupal platform to track prospects, services opportunities and client activity. The work exposed a recurring design question: when should a new feature reuse an existing record, and when does it deserve its own?

Start with the record that must endure

We already kept client billing details in a Drupal Client Profile attached to a User. We kept that model. A W&L-issued account number identifies the commercial relationship; a payment provider's customer ID does not.

This choice avoided a second account record with a second set of billing fields. It also left room for a future shared company account if several people need access to the same invoices. We will add that structure when the workflow needs it.

An inquiry may lead to a conversation, a proposal or nothing at all. None of those events should grant access to a client portal.

Prospects therefore live in private contact records. Opportunities hold the stage, owner and next action. Staff attach an existing client identity when they confirm a signed statement of work. Portal access remains a separate administrative step, with Paladin handling identity.

Testing made this boundary concrete. Drupal's usual user selector excludes blocked accounts. That is sensible for many login workflows, but staff still need to record activity before a client's invitation is activated. We added a staff-only selector for commercial references and tested that clients cannot use it.

Give each system one job

Chronicle owns the relationship and commercial record. Jira owns delivery tasks. The opportunity stores Jira keys so staff can move between the two without making project status the authority for a sale.

Statements of work, invoices and deliverables stay with the client User under File Gate. The CRM records a pointer to the approved statement of work and its revision. It does not take ownership of the document.

That distinction mattered in Drupal. An Entity Reference Revisions field can change a paragraph's parent. A convenient field type would have broken our document ownership rule. A non-owning reference with protected revision metadata preserved both the document's home and the evidence for the win.

A correct model still needs a useful interface

The first version passed its access and workflow checks, but staging use exposed a simpler problem: it felt like a set of administration forms. Opening an opportunity led straight to editing its fields. Staff needed context before they needed a form.

We studied Attio's record pages, Pipedrive's deal view and Close's Inbox. Each offered a useful lesson about keeping the next action close to the relationship's history.

The next iteration gives an opportunity its own workspace: stage, next step, contacts and recent activity, with editing as a secondary action. Recording an interaction starts with the opportunity selected and returns staff to the same page. Creation forms keep required information visible and group optional details.

The home page brings together due work, pipeline counts and recent activity. Its chart counts all opportunities the staff member may view. Its work queues remain short and label how many records are shown. Mixing those two counts would make a tidy chart tell the wrong story.

The interface uses our adaptation of an MIT-licensed ReUI Card component and the existing Recharts library inside Gin. Styles stay local, and Drupal still supplies usable HTML when the React enhancement is unavailable. A public template can guide a layout; each source component still needs its own license check.

Put rules beneath the form

Hiding a button is not an access control. We put permissions, stage transitions and revision checks in the services that save records. A stale edit is refused. A retry must match the original request. Marking an opportunity won requires the right client and an accessible, approved statement of work.

Review found another route around the intended stages: reopening a lost or parked opportunity could skip ahead. We tied reopening to the last active stage and added regression tests. The lesson was simple: test the paths back into a workflow as carefully as the path through it.

Reuse governance, then test the boundary

Chronicle already had Field Guard, File Gate, audit records and Sentinel. The CRM uses those controls. Governed tools expose a small set of operations for each staff function, with record limits and restricted output. They do not provide a general export of client profiles or documents.

We also tested direct tool execution. It must repeat the access check, even if its usual caller already performs one. And an audit event is useful only if the stored record retains the identifiers needed to explain the change. Our tests check the saved event, not just the call that attempted to write it.

For more on that foundation, read How Chronicle makes content operations auditable.

Build around decisions, not a field catalogue

Every extra field creates another fact to maintain. We kept the fields needed to identify a prospect, assign responsibility, record evidence and choose the next action. Payment processing, mailbox sync and financial forecasting remain separate work.

The useful measure of this extension is whether staff can answer a few ordinary questions with confidence: who owns the relationship, what was agreed, what happens next, and who may see it? Those questions gave the implementation its shape.