NextWorld Platform Capability Question: Time-Based Change / Promotion Freeze

Hi Nextworld,

We’re evaluating whether the NextWorld platform can support an automated, time-based freeze of changes before a production release.


Change & Edit Control

  1. Can Nextworld prevent or restrict object edits, checkouts, merges, or unlocks based on:

    • time (e.g., after a specific day/time), or

    • a system flag / configuration value?

  2. Are edit / checkout / merge actions permission-based, and can those permissions be:

    • toggled automatically, or

    • evaluated dynamically at runtime?


Promotion / Deployment Control

  1. Can NextWorld block or restrict promotions (e.g., via Promotion Manager or equivalent) based on:

    • time windows,

    • environment state, or

    • a configurable flag?

  2. Is there any pre-promotion validation hook or extensibility point where custom logic can allow or deny a promotion?


Automation & Scheduling

  1. Can scheduled jobs interact with security, permissions, or deployment controls?

Hello Pablo,

Regarding your question about supporting an automated, time-based freeze of metadata before a production release, the platform does not currently provide this feature set.

  • Change & Edit Control
    • The platform does not support a configurable time or system/configuration feature to allow one or more partners to freeze metadata changes.
    • The permissions for checkout/edit/merge are not fine-grained, and likely don’t support this use case. If a developer’s security role was revoked to prevent metadata edits, this would take effect for all environments the developer has access to which may not be desirable.
  • Promotion / Deployment Control

    • The platform does not currently provide a feature to control promotions for a tenant by time window, environment state, configuration flag, or pre-promotion validation hook that could be used to condition promotions.
  • Automation & Scheduling

    • You should not create scheduled jobs that are designed to mutate metadata objects such as permissions or roles.

This is a very valid request, and my recommendation is to get this formally added as a backlog Idea to have platform support considered. I would suggest a call/discussion to ensure the use cases are clear in terms of which pipeline environments need to have the restrictions implemented, and any that do not. It would also be helpful to better understand the automatic scheduling requirements.

2 Likes

Thank you Robert, for the confirmation! I will gather the requirements internally and then raise a enhancement request for this ask.