Therefore Ideas

Submit your feature requests for Therefore™!

versionning on Categories


When Therefore is in production and we need to update configuration of categories, we have two options:

  • Create new category from first one and modify this one

  • Modify category in live and we take the risk with users to have troubles.

If we create new category, when we want to pass the new one in production we have again two choice :

  • Block user for minimum half day, modify the old category with the dev category.

    • There is high risk to forget some fields or configuration and do mistake.

  • Ask user to use the new category for new document and old one only for read.

    • What happen with running workflow, need to use multicategory search if we don't know the date of document.

Suggestion :

It would be great to be able to modify existing category and do versionning on as we have on workflow.

As admin we could access in navigator to category in developpement, save new document out of prod category, start workflow out of prod workflow etc.

I think it could help admin really much to implement therefore solution if we could have another way to upgrade client configuration.

  • Etienne Baillieul
  • May 12 2022
  • Attach files
  • Verdi R-D commented
    16 May 05:21pm

    I 100% agree with this. Customer expectations, use cases, and design criteria are all mutable. While locking down project scope can help reduce the possibility of change in a project, change is inevitable. The usefulness of Therefore is directly dependent on its flexibility through the iterative design process.

    One issue category versioning could help solve: Later integration with third party systems through reference tables after project design.

    Customer A decides they want to track invoices alongside customer interactions in Therefore to provide the best customer service. Invoices originally stored in Therefore are linked to the customer with a unique key (Invoice No).

    Customer A finds a new wiz-bang invoice management tool that can tie into Therefore using reference tables to custom database views. Customer A files a project change request. Therefore technician now has to delete and recreate all referenced fields (primary and dependent) in the category while also migrating over all of the old documents linked to the wrong field.

    Current option for completing this task:

    1. Recreate the category according to the new category design.

    2. Link non-dependent objects to the new category. (Items like keyword dictionaries)

    3. Create a new workflow process that automatically changes category to the new category.

      1. Manually run this workflow process on all existing documents

    4. Migrate or recreate the workflow processes tied to the old category with the new index fields.

    5. Delete the old category and associated no longer relevant data structures.

    Hijacking this issue a little bit. There are a few processes that are very difficult to complete with the way that Therefore handles change to the category tree. Namely deletions. This process is particularly difficult if you wish to delete some structure that is highly dependent to other structures (categories, keyword dictionaries, reference tables, workflows). Therefore is aware of this dependency tree and won't allow you to delete one structure in isolation (as not to break things) but gives a cryptic warning as to what objects are still left linked. Further deleting those objects can be difficult because interpreting the original deletion message isn't always clear.

    As a new feature, it would be great if Therefore could provide greater detail on linked objects in the dependency tree that need to be deleted first as well as an auto resolve/remove all dependents feature that can help Therefore technicians remove test or irrelevant production data structures from a Therefore system.