Skip to main content
The History module lets you create a complete history of any table using a no-code SCD Type 2 template. Unlike Type 1 (which overwrites old data) or Type 3 (which stores limited history), the History module automatically creates new records for each change — making it perfect for tracking changes in customer information, product details, or employee records over time.

​
Creating a History

1

Select input table

Choose the source table containing the data you want to version. Make sure the table has a reliable way to detect changes.
2

Define primary keys

Specify the business keys that uniquely identify each record (e.g., customer_id, product_id). Nekt automatically creates a surrogate key for versioning.
3

Configure output settings

Select the output layer, name the history table, and set the run schedule. Choose from schedule-based, event-based, or manual triggers. See Triggers documentation for details.

​
Best Practices

Choose primary keys that are stable and will not change over the lifetime of a record. Changing primary keys mid-stream causes incorrect version boundaries and corrupts the historical chain.
Document the business rules that determine what counts as a meaningful change for each History. This context is easy to lose and hard to reconstruct later. Monitor storage growth and the number of changes detected per run. A sudden spike usually indicates an upstream data issue rather than genuine business activity.

​
Need Help?

Review the SCD Type 2 use case for a practical end-to-end example.

​
Use Cases

Customer churn prediction

ML models need versioned behavior history — plan downgrades, engagement drops — not just today’s snapshot. History provides that automatically without custom pipelines.

Lead scoring

CRM records change constantly. Versioned snapshots let scoring models understand when a lead’s profile improved or degraded over time, improving model accuracy.

Point-in-time context for LLMs

RAG pipelines and AI agents often need to know what was true at a specific moment. History makes it possible to reconstruct the state of any record at any point in time.

Feature drift & anomaly detection

ML monitoring compares current feature values against historical baselines. History creates and maintains those baselines without custom code.