A pipeline board looks like columns and cards. Underneath, it is a structured editor for business state. Moving a card is a record update, and removing a column can change the meaning of records that still use it.

In the CRM extension, I keep boards connected to native entities and permissions. The goal is to give records another useful working view while preserving their identity and behavior elsewhere in the CRM.

Separate stored values from presentation

A status needs a stable stored identity. Its label, color, order, and guidance can change without making existing records unrecognizable.

Conceptually, a column configuration contains:

stable status value
visible label
position and color
card presentation options
optional phase guidance

Using the translated label as the stored identity would couple language and workflow. Renaming a column would become a data migration instead of a presentation change.

The same distinction applies to card fields. Choosing which values appear on a card should not create a second copy of those values detached from the underlying entity.

A drag operation is an authorized write

The frontend can express the user's intention to move a card. The server still needs to verify the entity, record, current rights, and requested destination.

A board being visible is not proof that every card on it is editable. An administrator's successful drag test does not cover a read-only user or a user whose record access has changed since the board loaded.

After a move, reload should show the same state. Otherwise the interface may have demonstrated only an optimistic animation rather than a persisted transition.

Concurrent editing adds another case: a stale board view should not silently override a newer decision without the application's chosen conflict policy.

Protect occupied columns

Removing an empty custom column is fundamentally different from removing one that existing records still reference.

The release scope includes server-side protection for occupied custom columns. Records must be moved deliberately before removal. A guided bulk-transfer interface is a separate feature, not something implied by a delete button.

This keeps a metadata edit from silently destroying the interpretation of business records. It also makes the limitation understandable: the configuration cannot be removed while data still depends on it.

Package metadata and behavior together

A CRM extension spans more than its JavaScript view. Entity metadata, labels, layouts, PHP services, hooks, and database changes can depend on one another.

Copying a board view without its associated definitions can produce an interface that renders but fails during a save. Release preparation therefore needs an explicit file boundary and an isolated installation check.

For this work, the important evidence includes regular-user access, read-only behavior, drag and reload, occupied-column rejection, and preservation of existing record IDs. A convincing screenshot establishes appearance; those checks establish whether the board behaves like part of the CRM.