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.

​
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.

​
API & MCP

Platform API

Histories are transformations: list, update, trigger, and delete them.

MCP tools

No dedicated history tool yet.