Release 2026 Q1

2026.1: Deprecation / Critical Changes

• 🔥 New deadline calculation for stages: All future deadlines previously set for workflow stages will be removed. Instead of specific due dates for future stages, users will see duration information configured at the template level.
  
  Deadlines for each stage will only be set when a document enters that stage.
  
  

Automation

• Control Who Triggers Automations. Plus Loops prevention logic

  • You can now define exactly whose actions are allowed to trigger metadata-based automation rules: user-initiated changes, automation-initiated changes, or both.
    
    By default, only user actions trigger automation rules, which helps prevent noisy or looping automations while still allowing more advanced setups when you explicitly enable automation-driven triggers.
  • Use Cases:
    • Keep approval or notification flows reliable by allowing only human‑initiated metadata updates to trigger automations, so downstream actions always reflect intentional user changes.
    • Build chained workflows where one automation updates metadata and another rule reacts to that change, by enabling both user and automation initiators when you need fully automated flows.
    • Reduce unintended loops and duplicated executions by leaving the default “user only” setting in place for simpler policies, and enabling automation triggers only for carefully designed scenarios

• • To Consider:
    • 1. By default, only user‑initiated changes fire the rule; you need to explicitly enable automation‑initiated changes if you want automations to trigger other automations.
    • 2. 🔥 Aggregation logic prevents your rules from running multiple times when several metadata changes happen close together. Instead of triggering a new run for every single update, the system groups changes for a short window (for example, 10 seconds) and then executes the rule once using the latest state of the metadata.
       
      For example, multiple quick updates to the same metadata by a user (for example, changing the owner field several times in a row while deciding who to assign) may result in only a single automation run instead of one per change.
    • 3. 🔥 Loop protection logic ensures that when one automation updates metadata watched by another automation, that reaction will run only once, even if the second automation would normally trigger the first one again.
       
      For example, if Automation A updates a field that triggers Automation B, and Automation B then updates a field that could trigger Automation A, the system will allow this chain to run a single time and then stop further triggers, so you do not end up with A → B → A → B loops.

Other

• Legacy modules: The Exceptions and Compliance Assessments modules were removed.

2026.1: IMPORTANT changes in User Interface, Text, etc...

Workflow

Changes in Wording:

• Template Settings: "Set Stage" -> "Set Workflow"

• Document Settings: “Stages” → “Workflow”
• Top bar menu: “Change Stage” → “Next Stage”
• Stage Modal:
  • “Set Workflow” → Removed

White-Labelling

Brand colors available in all color pickers:

You can now apply your organization's brand colors consistently across the platform in all areas where color selection is available.

Brand colors are now available in the editor (text and background colors, including text styles and table colors), document type, automation actions (like emails) and various admin panel configurations.

Notes

• Use cases:
  • 1. Notify users automatically when key metadata changes, so they can respond without regularly checking records.
  • 2. Create or update follow‑up tasks when specific fields change (for example, routing documents to a new reviewer when ownership or business unit is updated).
  • 3. Keep downstream processes stable by allowing rules to react only to user‑initiated changes, reducing the risk of noisy or looping automations.
  • 4. Use broad “any custom fields change” monitoring where needed, or narrow rules down to a small set of critical fields for more targeted workflows.
  
  
• To Consider:
  • 
    1. 🔥 If you do not select specific fields, the rule will listen to changes in any custom metadata field, which may lead to more frequent automation runs than expected.
    
    
  • 2. By default, only user‑initiated changes fire the rule; you need to explicitly enable automation‑initiated changes if you want automations to trigger other automations.
    
    
  • 3. 🔥 Aggregation logic prevents your rules from running multiple times when several metadata changes happen close together. Instead of triggering a new run for every single update, the system groups changes for a short window (for example, 10 seconds) and then executes the rule once using the latest state of the metadata.
    
    For example, multiple quick updates to the same metadata by a user (for example, changing the owner field several times in a row while deciding who to assign) may result in only a single automation run instead of one per change.
    
    
  • 4. 🔥 Loop protection logic ensures that when one automation updates metadata watched by another automation, that reaction will run only once, even if the second automation would normally trigger the first one again.
    
    For example, if Automation A updates a field that triggers Automation B, and Automation B then updates a field that could trigger Automation A, the system will allow this chain to run a single time and then stop further triggers, so you do not end up with A → B → A → B loops.

Notes

• Use cases:
  • 1. Next Review Scheduling: Automatically set the “Next Review Date” to 10 days or 10 weekdays from today when a document is released.
  • 2. Expiry Planning: Predefine document expiry dates to occur a set time after key workflow stages.
  
  
• To Consider:
  • 1. Dates can be set based on a fixed number of days or weekdays added to the current date (“Today”). Only “Today” is available as a reference point at this stage.
  • 2. Manual adjustments are not prevented - users can still overwrite these fields if permitted by metadata screen configuration.
  • 3. Example with different options:
    
    10 Days from Today (12.11.2025) = 22 November 2025 (Saturday)
    
    10 Weekdays from Today (12.11.2025) = 26 November 2025 (Wednesday)
    
    ————————————————————————————————
    
    
    Future enhancements may expand the choice of reference fields (allowing selection from other date or number metadata fields)

Notes

• Use cases:
  • 1. Automatically set “Next Review Date” to one year from now when a document is released.
  • 2. Reset “What’s New” and “Major Changes” fields when a new version is created.
  • 3. Bulk clear obsolete metadata fields when documents are archived.
  
  
• To Consider:
  • 1. 🔥 Multiple automation rules within document can touch the same metadata field, and there is no way to ensure the order. When executing these automations, they may lead to different results as the order of execution changes. Careful design is recommended if several automations could target the same field.
  • 2. 🔥 Automation can update or clear any editable metadata field, even if the field is set as required or read-only on the metadata screen.
    Automations cannot update system locked metadata fields like (released date, publication date, etc)
  • 3. If automation contains multiple actions (like 1 send email, 2 update metadata, 3 send email) and a step fails, any subsequent steps (actions) in that rule will be skipped, helping you maintain data accuracy

Notes

• Use cases:
  • 1. Auto-progress documents: Automatically move a document to the next stage when all approvals are completed, so workflows continue without manual updates.
  • 2. Target specific stages: Route documents directly to a chosen stage (for example, Legal Review or Final Approval) when certain conditions are met, reducing coordination overhead.
  • 3. Quick stage navigation: Use
    Next/Previous stage buttons
    to move documents forward or back in the workflow while respecting boundaries like first draft and release.
  • 4. Transparent status tracking: Notify stakeholders whenever a stage changes, including who or which automation performed the action and when.
• To Consider:
  • 1. 🔥Automations cannot move a document beyond the last stage in the workflow or before the first stage, so “Next” and “Previous” are only available where a stage exists.
  • 2. 🔥 Using “Move to stage” will bypass the usual guardrails applied when changing stages manually. It will allow documents to skip mandatory stages, ignore required metadata fields, clear all rejected and pending approvals, and remove any paragraphs that are still pending.

Notes

• Use cases:
  • 1. Trigger workflow steps, such as moving a document to the next stage, when all approvals are granted.
  • 2. Instantly send summary updates to stakeholders when all required approvals are completed on a document.
  • 3. Automatically notify key team members whenever an approval status changes on critical documents.
• To Consider:
  • 1. 🔥 The trigger operates at the document level and emits individual events for each approval change.
    
    If multiple approvals are present (e.g., 10 approvals on a document), each change (added, approved, rejected, removed) will activate the automation separately, potentially resulting in numerous actions.
  • 2. 🔥 In case when new approver was added, only Added events will be triggered, pending status will be ignored in this case
    
    —-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-
    
    Future updates are planned to expose more detailed event data (who changed, when, which approval), which may improve how actions and notifications are handled.

Notes

• Use cases:
  • 1. Automate team notifications when a new document version or NMC version is created, helping stakeholders stay up to date with the latest policy changes.
  • 2. Automatically reset or update document metadata during versioning, minimizing risk of overlooked compliance data and ensuring accuracy with less manual effort.
  • 3. Configure custom workflow rules so that routine post-versioning actions, such as updating field values or sending alerts, run without manual intervention whenever a document advances to a new version or amended state.
• To Consider:
  • 1. The “New Version” event does not trigger for routine transitions like moving a document back to Draft, it only applies to actual creation of new versions.

Notes

• Use cases:
  • 1. Automatically move documents forward or trigger follow-up actions only when specific approval thresholds are reached (for example, when more than one approver has marked the document as Approved).
  • 2. Route documents differently based on metadata, such as product, region, or department, by configuring conditions that check metadata field values before running an action.
  • 3. Combine approval and metadata conditions using AND/OR logic to create precise rules, such as running an action only when a document is Approved and tagged with a specific risk category.
  • 4. Use multiple condition blocks within the same rule to introduce checkpoints across the automation flow, controlling which later steps should run based on how conditions are met at different stages.
• To Consider:
  • 1. 🔥 Condition blocks act as gates: any actions or later condition blocks placed after a block will only run if that block evaluates to true.
  • 2. You can place multiple condition blocks anywhere after the trigger and reuse the same metadata or approval fields more than once within a rule

Notes

• Use cases:
  • 1. Notification checks: Review which automated emails were sent from a document, including subject and recipients, to support compliance checks.
  • 2. Metadata change trace: Quickly confirm which metadata fields were updated by automation, and when, during an audit or investigation
  • 3. Automation Stage Tracking: See when a document was moved to a new stage by automation, helping you understand how it progressed through the workflow without manual checks.
  • 4. Noise Reduction: Hide low‑value automation email events from the activity timeline so you can focus on the critical updates and notifications that matter for audits and reviews.
  • 5. Filter the Document Activity log by the new Automation “user” to review only automation-related updates
  • 6. Export automation-related events (including before/after metadata values and notification details) for compliance checks or external reporting
  • 7. Deep-dive into runs: Jump from an automation event in the activity log to the Automation Audit log or execution run to understand exactly what happened.

• To Consider:
  • 1. 🔥 Only events triggered by automation are included, and only when the action was successful or partially successful (for example, emails sent to some but not all recipients)
  • 2. Details for email events show the final resolved recipients and content, but do not expose groups or smart values as configured in the automation rule
  • 3. What you can open from an automation event depends on your permissions: Users with Manage Automation authority can drill into automation logs, Document owners can view information about runs, while other users see read-only information

Notes

• Use cases:
  • 1. Automation Run Review: See each step executed in order, including stage changes, metadata updates, and condition checks, so you can quickly confirm whether the rule behaved as intended.
  • 2. Issue Investigation: When a document ends up in an unexpected stage or with incorrect metadata, review the related automation run log to pinpoint which action or condition caused the outcome and adjust the rule configuration accordingly.
  • 3. Audit Evidence: Export the detailed automation log for a key document or workflow as supporting evidence for internal audits, regulatory reviews, or incident analysis, showing exactly which rules ran and what they changed.
  • 4. Support Troubleshooting: teams can use the automation audit log to reproduce and understand issues without external help, reducing time to resolution.

Notes

• Use cases:
  • 1. Transition to a Metadata engine - Hierarchical Select fields
• To Consider:
  • 1. 🔥 As part of Beta Phase will be introduced only on beta and UAT environments.
  • 2. Enabling this configuration removes all category visibility across the platform’s common section and impacts all modules. Categories will be fully hidden from document lists, columns, sidebar, search results, creation workflows, move-to-stage flows, and document/template settings.
  • 3. Data integrity remains intact. Even when categories are hidden, all underlying category data is preserved and no data loss occurs. The operation is reversible; showing categories again restores full access to previously assigned categories.
  • 4. 🔥 Search results will no longer display category fields when this is enabled. Hiding categories does not affect existing settings or filters, which remain active.
  • 5. Existing documents with previously assigned categories are not reclassified or deleted when categories are hidden.

Notes

• Use cases:
  • 1. Easily organize complex, multiline metadata with advanced table configurations.
  • 2. Format metadata tables to align with organizational needs using text and background styling options.
  • 3. Gain control over the layout and presentation of metadata for improved clarity and precision.

Notes

• Use cases:
  • 1. Configure certain workflow stages without deadlines, allowing alignment with your internal review process or exceptions.
  • 2. Rely on automatic calculation of stage deadlines based on template settings, so you don’t need to manually adjust deadlines each time a document enters a new stage.
  • 3. Restrict who can edit deadlines supporting your organization's governance and compliance policies.
• To Consider:
  • 1. 🔥 After migration, all future deadlines previously set for workflow stages will be removed. Instead of specific due dates for future stages, users will see duration information configured at the template level. Deadlines for each stage will only be set when a document enters that stage.
  • 2. If the template is configured to allow deadline editing, the Document Owner can adjust stage deadlines.
    
    - Roles such as Document Manager or Superadmin always have permission to update any stage deadline at the document level, regardless of template restrictions.
    
    Note: they should add themselves as document owners to the document where they want to update the deadline.
  • 3. The duration field, when linked to a template, is not editable at the document level and can only be adjusted by updating the template itself.

Notes

• Use cases:
  • 1. Quickly confirm whether a document is using the default or Non-material Changes workflow directly from the stage modal, reducing the risk of sending a document through the wrong workflow.
  • 2. Access workflow settings from the stage modal to fine-tune stage configuration, making it easier to keep workflows aligned with internal requirements.