Skip to content
CogniYukti

Records

A company is rarely one company.

It is a parent that signs, a subsidiary that uses the product, and a third entity that pays the invoice — and the deal, the contract and the receipt all belong to different ones.

Flatten that and you get the same customer three times, with the renewal attached to whichever row somebody opened first.

Hierarchy

Parent and child, with the loop refused where it cannot be argued with.

An account can have a parent, and the chain is walked upward as a breadcrumb wherever you are. Subsidiaries are listed on the parent with their own counts, so a renewal conversation can see the whole relationship rather than the one entity that happened to sign.

The guards against nonsense are in the database rather than only in the form — an account cannot be its own parent, a cycle is refused by name, and the chain stops at ten deep. That matters because the reorganisation that breaks a hierarchy is almost never done through the form. It is done by an import, or a script, at eleven at night.

One buying relationship, four legal entities
  • Halvorsen GroupParent · 3 subsidiaries
  • Halvorsen Nordics ABSweden · 41 contacts
  • Halvorsen Logistics OyFinland · 12 contacts
  • Halvorsen Freight LtdUK · 6 contacts
Refused in the database, not only in the form
  • an account cannot be its own parent
  • a cycle is refused, and named
  • the tree stops at ten deep

Which matters because the reorganisation that breaks a hierarchy is usually done by an import or a script, not by somebody using the form.

Illustrative
  • Five statuses, and one is not allowed in bulk

    Prospect, active, churned, former — and blocked, which is deliberately excluded from the bulk action. Blocking carries a reason and usually means cleaning up open deals and live contracts, so it needs a conversation rather than a checkbox on forty rows.

  • Bulk tells you what it skipped, and why

    Not a count. Per row: not found, not permitted, already in that status. A bulk action can never launder a permission you do not hold on an individual record — every row is checked again.

  • Reassigning can cascade, and reports the two numbers separately

    Two accounts, and fourteen linked contacts and deals. So you can see what the cascade actually did rather than trusting that it did something.

  • Tax identity is a field, not a custom field

    Because it is printed on the bill-to block of every quote, order and invoice, and a field the document depends on should not be something somebody can rename.

Merging two of the same company

The survivor inherits what it was missing, and the record says which fields moved.

Where the survivor has a blank and the loser had a value, the value moves — across eighteen named fields. Where both have a value and they disagree, the survivor's wins. The audit records which fields were filled, by name, so "where did that industry come from" is answerable later.

Everything pointing at the loser is moved to the survivor. Which sounds obvious until you have watched a merge quietly orphan half a timeline because a newer part of the product added a link nobody remembered. Here every relationship is declared in one place, and the build fails if a new one is added without being declared — a whole class of bug turned into a failing test.

  • An empty string counts as blank. Zero does not.

    So a genuine zero on the survivor is never overwritten by the loser's number, and an empty text box never blocks an inheritance.

  • Saving a company from a profile page is idempotent

    Save the same company twice and you get the existing account back, told that it already existed — rather than a second one to merge later.

Can a merge be undone?

Not at the account level. A merge is one survivor and one loser, applied in full — there is no field-by-field choice at the point of merging and no unmerge. Where both records held a different value, the loser's is gone. Merge deliberately, and prefer the duplicate queue's suggestion to a hand-picked pair.

Is there an account team, the way a deal has collaborators?

No. A deal can have collaborators who gain access through it; an account cannot. Account access is ownership, team and explicit shares.

Can I page through a long account list?

Not today. Lists return a capped page with no next-page control — you narrow with the search box and the filters, or export. Worth knowing before importing fifty thousand accounts.

Do territories change who owns an account?

No. A territory classifies an account; it does not reassign it. See the territories page — that distinction is the whole of it.