Creating fields on the Document table isn't the sort of thing you want to do at any old time for fun – but the work is essential for normalization projects in Relativity whether you're using Chronicle or not. But you can also normalize faster with Chronicle when you create fields ahead of time.
Keep this best practice in mind to ensure you're keeping everyone working at optimal speed whenever you're asked to prepare a Privilege Log (or any other task in Relativity) that requires normalization.
Keeping data away from the busyness of the Document table.
Most of Chronicle's work product lives outside of core Relativity tables. Chronicle uses its own set of tables to store the values that it identifies and the normalizations that users create for those values. So, for the vast majority of the time that you are normalizing, the core Relativity tables (looking at you, Document table!) are not impacted.
But normalized values DO need to be written back to Relativity fields.
In the final step of the normalization process, however, the normalized values need to be written back to fields in the Document table. If no fields are already defined to store these normalizations, Chronicle can create them automatically.
Since this last step isn't run automatically, you don't have to worry about Chronicle going rogue and doing DB-heavy work independently. However, it's still possible for a user to kick it off at an inopportune time and with the option selected to create new fields on the Document table.
Why wait for kick-off to get started when you know your case data?
Chronicle allows you to select a pre-existing field as the destination for normalized values. Therefore, having those in place before you reach the last normalization step is a great best practice for when you want to normalize faster.
There are likely several fields to normalize in every case, so getting those fields into the case (or even the case template) ahead of starting a normalization project makes it much more manageable once the project begins. Since this can be completed ahead of time, there's no need to worry about new columns being added to the Document table while reviewers are hard at work.
However, whenever you get the fields in there, by creating them early, you'll save the team time on the backend when speed is truly of the essence.
Comments