Version Control Using Filters

Best Practice: Versioning for Datastore-Based Selection Parts

When a template is exported from one Object Lifcycle Manager (OLM) installation and imported into another, it is common that the selection values in datastore-driven fields differ between environments. For example, Production might contain a different list of options than Test, or new values may be added over time.

To avoid creating multiple datastore parameters for each environment—and to prevent migration issues—you can use version-based filtering. By setting up version filtering from the start, you gain full control over which values are shown in which environment, without modifying existing records.

---

1. Preparing the datastore

For every datastore that is used as a source for a selection part, follow these steps:

1. Add a datastore field named filter_version This field stores the version number used for filtering.

2. Set the initial version number (001) for all existing entries This ensures that all values currently in use belong to version 001.

---

2. Configuring the filter in the part

When using this datastore as a source in a part, configure the filter using Filter type: Plain text and apply:

[{ "fieldname": "filter_versie", "filteroperator": "contains", "filtervalue": "001" }]

This ensures that only values belonging to version 001 are shown in the dropdown.

---

3. Updating values without affecting existing data

At some point, you may need to modify the list of selectable values— for example, because:

• a new environment requires different options

• old values must be phased out

• new values should only apply to new records

Instead of deleting or overwriting existing values (which can damage existing objects), you can extend the version filter.

Follow these steps:

Step 1 — Add the new version number

Add "002" to the filter_version field of the new datastore entries. Do not remove "001" from existing entries, as older objects still depend on the old values.

Step 2 — Update the part filter

In the template editor, update the filter to target version 002:

[{ "fieldname": "filter_versie", "filteroperator": "contains", "filtervalue": "002" }]

Newly created objects will now only see the version 002 values, while existing objects continue to access version 001.

---

4. Result: Flexible, safe versioning

With this version-based filtering method:

• You can safely introduce new sets of values

• You can control exactly which version applies to which template or environment

• You avoid breaking existing records or references

• You prevent the need for separate datastore parameters per environment

This approach should always be applied from the beginning, because adding versioning later requires manual database operations by the support team.

---

Important Notes

• Dynamic values should not be wrapped in quotes.

• Quotes are only necessary for hardcoded values, such as "v001".

• A correct dynamic filtering example looks like this:

[
  { "fieldname": "Version", "filtervalue": "v001" },
  { "connector": "and", "fieldname": "Filter", "filtervalue": #REPLACE-PARTVALUE-Faculty_promotor||# }
]