Active Policy supports both global policies that apply to all users and specific policy overrides for individual users or roles, allowing independent testing of different builds or branches.
Key concepts
Active build
- The active build is the currently selected version of a project that is deployed in the runtime environment. It is the version that all process executions will reference when initiated.
- While a global policy applies to all users by default, individual policy overrides can specify different active builds for specific users or roles.
Policy types
- Latest on Branch: Configures the project to run the latest version on a specific branch. This is useful for environments like development or testing, where ongoing changes need to be reflected in real-time.
- Build: Points to a specific build from the available builds for the project. This policy ensures that only the selected build is used, preventing unexpected updates. It is typically used for UAT and Production environments.
Policy hierarchy
- Global Policy: The default policy that applies to all users unless overridden.
- Policy Overrides: User-specific or role-specific policies that take precedence over the global policy for targeted users.
- Policy overrides enable independent testing of different builds or branches without affecting other users.
Version control and flexibility
- Active Policy provides flexibility by allowing different users to work with different build versions simultaneously.
- By managing both global policies and overrides, you control which changes go live for which users and when, allowing for seamless testing and controlled rollouts.
Global policy
The Global Policy section defines the default active policy that applies to all users unless specifically overridden by individual policy overrides.
1
Navigate to Active Policy
Go to your project’s Runtime Settings and select the Active Policy tab.
2
Configure Global Policy
In the Global Policy section, choose your policy type:
- Latest on Branch: Always use the latest version on the selected branch
- Build: Usa specific build from the available builds for the project
3
Update Policy
Click Update to apply the global policy changes.
The policy takes effect immediately for all users without specific overrides.
Policy overrides
Policy Overrides allow you to define specific active policies for individual users or roles, enabling independent testing of different builds or branches without affecting the global policy.
Define policies for specific users or roles to simulate conditions and test branch behavior independently from the global policy.
Managing policy overrides
The Policy Overrides section provides comprehensive tools for creating, managing, and monitoring user-specific and role-specific active policies.Override table structure
The policy overrides are displayed in a table with the following columns:- Override Type: Specifies whether the override applies to a Username or Role.
- Applies To: Indicates the specific Runtime User (by username) or Runtime Role (by role name) that this policy override applies to.
- Policy: Specifies the policy type to use for the override.
- Branch/Build Version: Specifies the branch or build version to use for the override.
- Priority: Specifies the priority of the override.
- Status: Shows whether the override is Active or Inactive.
Search and filter
Use the search functionality to quickly locate specific overrides:- Search by Username: Enter a username to filter overrides for specific users
- Search by Role: Enter a role name to filter overrides for specific roles
- The search filters the table in real-time as you type
1
Add New Override
Click the Add button (+ icon) to create a new policy override.
2
Configure Override Type
Select whether the override applies to a Username or Role:
- Username: Choose a specific user from the dropdown
- Role: Select a role from the available options
3
Set Policy Configuration
Choose the policy type:
- Latest on Branch: Select the branch to use
- Build: Choose a specific build version
4
Set Priority
Assign a priority number to handle conflicts when multiple overrides could apply.
Priority is mandatory for role-based overrides and must be unique across all role overrides.
Lower numbers = higher priority. Use priority 0 for the most critical overrides.
5
Enable Override
Check Enable this override to activate it immediately, or leave unchecked to create it in an inactive state.
6
Create Override
Click Create Override to save the new policy override.
The override appears in the table and takes effect immediately if enabled.
Override management actions
Each override in the table provides several management options: Edit Override- Click the edit icon to modify override settings
- Update policy type, target build/branch, or priority
- Changes take effect immediately upon saving
- Activate/Deactivate: Toggle the override on or off without deleting it
- Delete: Permanently remove the override
Deleting an override immediately reverts affected users to the global policy. Ensure this change is intentional.
Key features
Environment-specific control
- Each environment can have its own global policy and set of policy overrides
- Control what version of the project runs for different user groups at each stage of development
User-specific testing
- Policy overrides enable individual users or roles to test different builds independently
- Developers can work and test their ongoing work simultaneously without conflicts
- QA teams can test specific builds while production users remain on stable versions
Priority-based resolution
- When multiple overrides could apply, priority determines which takes precedence
- Fine-grained control over policy application in complex scenarios
- Clear hierarchy: User overrides > Role overrides > Global policy
Rollback capability
- Easily revert to previous builds by updating the global policy or specific overrides
- Quick rollback minimizes disruption and maintains system stability
- Independent rollback for specific users without affecting others
Branch-specific management
- Support for branch-based policies in both global settings and overrides
- Parallel development with different active branches for different user groups
- Flexible testing scenarios across multiple development streams
Benefits
- Controlled Rollouts: Gradual deployment to specific users or roles before wider release
- Independent Testing: Users can test different builds simultaneously without conflicts
- Enhanced Stability: Risk mitigation through targeted deployment and easy rollback
- Flexible Development: Support for parallel development streams and testing scenarios
- User-Centric Control: Granular policy management at the user and role level
- Priority Management: Clear resolution when multiple policies could apply
Permissions and access control
Active Policy management requires appropriate permissions to ensure secure and controlled access to policy configuration.Access to Active Policy settings should be strictly controlled as changes can affect production environments and user experience.
Required permissions
- View Active Policy: Required to view current global policy and policy overrides
- Manage Global Policy: Required to modify the global active policy settings
- Manage Policy Overrides: Required to create, edit, activate/deactivate, and delete policy overrides
- Admin Access: Full access to all active policy features and settings
Permission enforcement
- Unauthorized actions are blocked with clear denial messages
- All policy changes are audited with user identification and timestamps
- Role-based access ensures users can only perform actions within their authorization level
Contact your system administrator if you need additional permissions to manage active policies.
Technical details
Policy resolution hierarchy
When a user accesses the runtime environment, the system resolves their active policy using this hierarchy:- User-specific overrides (highest priority)
- Role-specific overrides (if no user override exists)
- Global policy (default fallback)
Priority-based override resolution
- When multiple role overrides could apply to a user, the override with the lowest priority number takes precedence
- User-specific overrides always take precedence over role-based overrides regardless of priority
- Priority numbers must be unique for role-based overrides and are mandatory
- Priority is particularly important when users are assigned multiple roles, ensuring deterministic policy resolution
- Priority numbers help resolve conflicts in complex role hierarchies
In scenarios where a user has multiple roles (e.g., DEVELOPER and QA_TESTER), the system uses the role override with the lowest priority number to determine their active policy.
Project context and resource references
- The active policy system determines how resource references are handled during process execution
- At runtime, the system identifies the active build based on the resolved policy for each user
- Ensures correct resource definitions are used based on user-specific or global policies
Metadata and versioning
- Each policy (global and overrides) includes comprehensive metadata:
- Build ID and version tags
- Branch references and commit information
- User/role assignments and priority settings
- Creation and modification timestamps
Audit and monitoring
- All policy changes are logged with detailed audit information:
- User performing the action
- Timestamp of the change
- Before and after values
- Action type (create, update, delete, activate, deactivate)
- Audit logs are accessible to authorized users for compliance and troubleshooting
Storage and management
- Active policies and overrides are stored separately from build data
- Policy changes don’t affect build integrity
- Efficient policy resolution at runtime with minimal performance impact
- Scalable architecture supports complex override scenarios
Example use cases
Scenario 1: Feature testing with user overrides
A development team collaborates on a project where all features are merged into themain branch.
To support this workflow, set a policy override for each developer, pointing to the feature branch they are currently working on. When a developer merges their branch, update their override to either deactivate it or assign it to their next active feature branch. This approach ensures developers can test their work in isolation without impacting the main environment or other users.
1
Set Global Policy
Set the global policy to use the latest build on the
main branch. This ensures all users without overrides receive the most up-to-date production version by default.2
Set User-Specific Policy Override
Set a policy override for each developer, assigning it to the feature branch they are currently working on:
- Override Type: User
- Applies To: Individual developer (e.g.,
alice@company.com) - Policy: Latest on Branch
- Branch: Developer’s active feature branch (e.g.,
feature/alice-new-payment-flow) - Priority: 1
- Deactivate the override if no new feature branch is active, or
- Reassign the override to the next feature branch they are working on
3
Test Independently
Developers can now test the new feature while production users continue using the stable build.
No impact on production users during feature development and testing.
Scenario 2: Gradual rollout with priority management
Rolling out a new version to different user groups:1
QA Testing Override
Create high-priority override for QA team:
- Role:
QA_TESTER - Policy: Build
v2.2.0-rc1 - Priority: 0 (highest)
2
Beta User Override
Create override for beta users:
- Role:
BETA_USER - Policy: Build
v2.2.0-rc1 - Priority: 1
3
Production Rollout
After successful testing, update the global policy to
v2.2.0 and remove overrides.Controlled rollout minimizes risk and ensures thorough testing.
Scenario 3: Emergency rollback
Quickly roll back from a problematic build by downgrading the global active policy:1
Identify Issue
A critical issue is discovered in the current production build
v2.3.0.2
Downgrade Global Policy
Update the global active policy to point to the previous stable build (e.g.,
v2.2.5).All users will immediately use the stable build, ensuring a consistent and safe rollback.
3
Restore Latest Version
After resolving the issue, update the global policy to the new stable build (e.g.,
v2.3.1 or a fixed v2.3.0).For emergency rollbacks, prefer downgrading the global active policy instead of using overrides. This approach is simpler, avoids confusion, and ensures all users are aligned on the same stable version.
Conclusion
The Active Policy feature in FlowX.AI provides comprehensive control over project version management through both global policies and granular policy overrides. This dual-layer approach enables:- Flexible Testing: Independent testing of different builds and branches by different user groups
- Controlled Deployment: Gradual rollouts with priority-based conflict resolution
- Enhanced Stability: Quick rollback capabilities and isolated testing environments
- User-Centric Management: Granular control at both user and role levels
Start with simple global policies and gradually introduce overrides as your testing and deployment needs become more complex.