Skip to content
Work
Enterprise CRMPublic anonymized

Operational CRM

Software ArchitectureBackend EngineeringTechnical Leadership

Relationships, workflows, permissions, and a path off a legacy system

Domain modeling and workflow engineering

Context

The previous CRM could not express the real graph: institutes related to contacts related to applicants related to tasks, with permissions that were not “admin or not.”

System boundary

In scope

  • relationship model
  • filters
  • boards
  • permissions
  • migration

Out of scope

marketing automation blasts

Architecture

Entities are nodes with typed edges. Status is a workflow on an entity, not a column that everyone edits. Permissions attach to relationship and role, not to a hidden screen flag.

An anonymized operational CRM: institutes, contacts, applicants, tasks, statuses, and granular permissions — including migration from a legacy store.
  1. Institutes
  2. Contacts
  3. Applicants
  4. Tasks
  5. Statuses
  6. Permissions
  • Typed edges
  • Permissions are data
Published sequence
  1. Institutes
  2. Contacts
  3. Applicants
  4. Tasks
  5. Statuses
  6. Permissions
Stages on each row
  • Row 12Contacts · Applicants
  • Row 23Tasks · Statuses · Permissions
Roles in the diagram
  • service2
  • process1
  • store2
  • interface1

Counts from the published record. They describe structure, not a measured result.

How do the system domains relate?

relationships

  • storeInstitutes
  • storeContacts

workflow

  • processApplicants
  • serviceTasks
  • serviceStatuses

policy

  • interfacePermissions
  1. InstitutesContacts
  2. InstitutesApplicants
  3. ContactsApplicants
  4. ApplicantsTasks
  5. ApplicantsStatuses
  6. ContactsPermissions
  7. InstitutesPermissions

Critical flows

  1. An institute owns contacts

  2. an applicant is linked

  3. tasks and statuses move the case

  4. permission checks decide who sees which edge.

Stages

  • Relationship graph
  • Applicant workflows
  • Granular permissions
  • Operational boards

Decisions

01

Graph before screens

If the model cannot say “this contact at this institute,” the UI will lie.

02

Permissions are data

A new role must be configurable without a deploy. Hardcoded admin checks do not survive the client.

03

Migrate with dual write, then cut

Legacy import is a project. Shadow reads until the graph is complete.

When it fails

ConditionDetectionResponse
Orphan applicantRequired institute/contact edgeBlock create
Permission missPolicy denyEmpty result, not 500
Legacy id collisionImport keymapHalt batch; keep map

Infrastructure

  • Application
  • relational store
  • search/filter indexes
  • queued migration jobs
  • audit of permission changes

Outcome

Operations run on an explicit relationship graph with permissions that match how the organisation actually works.

Current state

In production as an anonymized public record. Legacy cutover complete for the published scope.

  • Laravel
  • PostgreSQL
  • Permissions
  • Workflows
  • Filters
  • Legacy migration
Contact