Integration glossary
Soft delete and delete propagation
A soft delete marks a record as deleted and keeps the row, usually with the date it was deleted. Delete propagation passes a delete made in one system on to the other systems that hold the same record.
Hard and soft deletes
A hard delete removes the row. It is simple and leaves nothing behind, and the history goes with it: a report run next month cannot show that the record ever existed.
A soft delete sets a flag, often with a date, and leaves the row in place. Screens and reports hide the flagged rows, while the history stays available to the people who need it.
Why deletes need a decision
When systems share records, a delete in one of them raises a question the others cannot answer by themselves. A customer closed in the CRM may still owe money in billing, and an asset retired in one register may still be on a technician's job list.
-
Decide for each kind of record whether a delete should travel at all.
-
Mark records deleted where history matters, such as invoices and payments.
-
Make sure a delete never travels back to the system it came from.
-
Remember that a soft delete keeps personal data, so erasure requests need their own handling.
Deletes in STRAX
Deletes in STRAX are switched on per table mapping and are off by default, so the hub keeps a record that a source removes. A mapping can instead mark the hub record deleted, keeping the row and the date, and the mappings to other systems can pass the delete on, either removing the row there or setting a column that means deleted. A delete is never sent back to the system it came from, and portal pages built on hub tables hide records marked deleted.
How the STRAX integration engine works → What change data capture is → Data movement, in the documentation →
More terms
Other ideas worth knowing.
Worker pool and horizontal scaling
A group of machines sharing one queue of work, so capacity grows by adding another machine to the pool.
Read the definition →Report theme
A saved set of colours, fonts, logo and cover design that every report using it is rendered with.
Read the definition →Script library
Shared, versioned code that workflow code steps can call, kept in one place with its licences and the workflows that use it.
Read the definition →See it on your own systems.
A demo takes about an hour and shows these ideas working on systems like yours.