Administration Enhancements

Centralized Authorization Service

BigFix Service Management now introduces a centralized Authorization Service that modernizes how access control is defined, enforced, and governed across the platform. This enhancement replaces legacy, hardcoded authorization in individual services with a configurable, policy-driven model that improves security consistency, scalability, and operational efficiency.

Legacy Decentralized Authorization

In the legacy system, authorization was enforced locally inside each microservice (for example, CMDB, D2C, and other domain services), with access rules hardcoded in UI forms and API code.

This decentralized model made it difficult to maintain a unified security posture, slowed down change delivery, and pushed all authorization load directly onto domain services, creating performance and reliability risks under high traffic.

With this release, BigFix Service Management transitions to a centralized authorization model, where access controls are managed by a dedicated Authorization Service instead of being embedded in each application. Authorization enforcement is now centralized and configurable, UI-level behavior is controlled via UI Builder, and hardcoded checks are gradually removed from APIs and replaced with flexible rules in the Authz engine.

At runtime, the Authorization Service acts as a central “Is this request authorized?” checkpoint, typically at the API gateway or service entry point. Only authorized requests are passed through to the underlying domain services, significantly reducing unnecessary processing and improving overall performance and resilience.

A key benefit of this design is source-level blocking, where RBAC via the central Authz engine implements a “fail fast” shield that stops unauthorized calls before they reach business services. This not only reduces load on downstream systems but also simplifies troubleshooting and auditing, because decisions and denials are recorded in a single place.

The new model also accelerates delivery for custom access control requirements by standardizing the enhancement process. Teams can now configure pages and visibility via UI Builder and then decouple or remove legacy hardcoded checks from the API layer, resulting in faster, safer rollout of new access policies.

The Authorization Service supports both Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) to cover a wide range of use cases. RBAC grants permissions based on a user’s role or job function (“I am a Role, therefore I can Action”), while ABAC uses contextual attributes from the user, record, and request (“I can Action if my Attribute matches the record’s Attribute”) to deliver fine-grained, dynamic policies.

Together, these models are implemented through a 360° security approach that evaluates three contexts simultaneously for every transaction: the User context (who is acting, such as company, role, group, location), the Request context (what is being asked, including payload and input data), and the Record context (what is the state of the data, such as status, owner, or created date). This ensures each action is not only allowed by role but also appropriate for the specific record and situation.

To support this, the release introduces a Resource Registry that defines what is being protected. APIs are registered as resources for granular action-level policies, while tables are represented via a Data Dictionary to drive table-based rules, making it possible to author policies that anchor on business data rather than just endpoints.

Under the hood, APIs are mapped to their underlying database tables to create a unified resource model. This mapping enables immediate context-aware policy authoring today, and it lays the foundation for “table-as-a-resource” protection and policy deduplication in future releases, where a single table-level rule can secure all related API endpoints (“write once, protect everywhere”).

On the administration side, a new Role menu is now available under the Foundation module, allowing admins to view all system roles and define new custom roles tailored to company-specific needs. These roles can be assigned to users and groups, with the user experience shaped by mapping application menus and modules to each role, controlling which areas of the application are accessible.

To expose forms and pages to the right audiences, admins with Super Admin rights can use UI Builder’s interactive screens to map custom roles to specific forms. This makes UI-level access control configurable and aligned with the centralized authorization model, rather than baked into front-end code.

Finally, administrators with the Authorization Admin role can define authorization rules directly from the new Authorization → Rules menu. Here, they can author and manage the policies that the Authorization Service evaluates at runtime, combining roles and attributes as needed to enforce both coarse-grained and fine-grained access controls.

Authorization Rule Override for Privileged Roles

We are introducing the ability for administrators to override default authorization (AuthZ) rules, allowing you to establish custom, company-specific access policies. This provides greater flexibility and control over permissions within your instance.

Who can override:

• Super Admins: Can override product default rules to create:
  • Instance-wide rules: Designated with "Default" company scope.
  • Company-specific rules.
• Standard Admins: Can create company-specific rules only.

Rule Resolution Priority:

When the system checks for a rule, it now resolves permissions based on the following hierarchy (highest priority first):

• Company Rules
• Instance Rules
• Product Default Rules

How to Override a Rule:

How to Override a Rule:

1. In the AuthZ rule list view, select the product default rule you wish to customize.

2. Click the 'Override' action in the preview section

   

3. In the pop-up window, select the target Company and Business Function.
4. Enter a new, unique name for the custom rule and click Override

   The new rule will be created as a copy of the original default rule. For tracking purposes, the 'Overrides' field will automatically populate with the name of the original product default rule.

   

Introduction of the 'Is Anything' Operator in AuthZ Rules

A new "Is Anything" operator is added to Authorization (AuthZ) rule conditions. This operator allows administrators to define rules that bypass standard data restrictions, ensuring that high-privilege roles maintain full access even when they also hold more restricted roles.

Previously, if a user had both a "Super Admin" role (unrestricted) and a standard "Admin" role (restricted by company), the system would apply the company restriction to both roles. By using the "Is Anything" operator, you can now ensure the Super Admin's "Allow All" logic takes precedence, resolving potential access conflicts.

Introduction of the 'Role' Attribute on AuthZ Rules

A new 'Role' attribute has been added to Authorization (AuthZ) rules to enable precise filtering based on user roles.

Administrators can specify one or more roles during the rule drafting process. When the system evaluates these rules, it will match them against the user's assigned roles, ensuring that only applicable rules are executed for each user.

Configurable User Types

Administrators can now define and configure company-specific User Types to better fit organizational needs. This customization capability allows each company within a multi-tenant environment to establish user classifications that align with their unique operational requirements.

User Types are configured via the company menu list API, providing programmatic control over user type definitions.

If company-specific user types are configured, the system's default user types will no longer be available for that company. Default user types remain accessible only when no company-specific types have been defined.

Organizations can create user types such as "External Consultant," "Temporary Staff," "Vendor," "Contractor," or any other classification relevant to their workforce structure and service delivery model.

New 'Service Account' User Type

A dedicated 'Service Account' user type has been introduced specifically for system integrations and automated processes. This user type distinguishes machine-to-machine interactions from human user activities, enabling better audit trails and specialized handling of system-generated requests.

When an incident is created through a 'Service Account' user type, the Incident Location field is automatically populated with the Location associated with the affected Configuration Item (CI). This ensures accurate geographical and organizational context without requiring manual intervention or complex scripting.

This enhancement improves integration reliability, reduces API payload complexity, and ensures consistent data quality for incidents created via automated monitoring tools, third-party integrations, or scheduled processes.

Default 'Template User' Role

The 'Template user' role is now assigned automatically upon user profile creation, streamlining the onboarding process and improving new user experience.

This automatic role assignment grants users’ immediate access to existing templates for Incident, Change, and Fulfillment processes without requiring manual administrator intervention. Users can begin creating service requests using pre-defined templates as soon as their account is provisioned.

By eliminating the need for manual role assignment during user provisioning, IT teams can reduce onboarding time and ensure consistent access policies across the organization. This is particularly valuable for enterprises with high user turnover or frequent contractor engagements.

Enhanced Location Picker

The user experience when associating a Location with a User Profile has been improved to ensure accurate selection and reduce data quality issues arising from ambiguous location names.

Context-Rich Search: When searching for a location, the dropdown now displays comprehensive identifiers in the format: Location Name | Location Type | Country | State | City. This helps users distinguish between similarly named locations (such as multiple "Main Office" entries across different regions).

Post-selection, an information (i) icon appears next to the field. Clicking this icon reveals the complete details of the selected location record, including Company association, full Address, Zip Code, and Description.

These enhancements reduce location misassignment errors, improve reporting accuracy for location-based analytics, service assignment rules, and compliance requirements.

SCIM Auto-Provisioning for Organizations & Departments

The SCIM (System for Cross-domain Identity Management) user creation and update process has been enhanced to automatically generate missing organizational hierarchy data, eliminating synchronization failures and reducing manual administrative overhead.

Organization Auto-Creation: When a SCIM request references an organization that does not exist in Active status for the specified Company, the system automatically creates a new Organization record.

Department Auto-Creation: If a department does not exist in Active status for the specified Company and Organization combination, the system automatically creates the required Department record.

While multiple records may share the same name across different companies or in different status states, the system ensures only one record remains Active per company at any given time.

More details around SCIM Integration can be found in the SCIM Integration Documentation.

Company-Scoped Data Uniqueness

Uniqueness constraints for Employee Number on the user table, and for Location, Organization, Department, and Cost Center names are no longer enforced at the Instance level. This represents a significant enhancement for multi-tenant deployments and managed service provider (MSP) environments.

These values must now be unique only within their specific Company context. Two different companies sharing the same instance can use identical Employee Numbers, Location names, Organization names, Department names, or Cost Center names without triggering conflicts or validation errors.

Multi-Tenant Benefits:

• Managed Service Providers (MSPs) hosting multiple client companies on a single instance
• Enterprise conglomerates with autonomous subsidiaries maintaining independent naming conventions
• Global organizations where regional entities prefer localized naming standards

Department Name Character Limit

The character limit for Department names has been increased from 150 to 250 characters to accommodate longer naming conventions often required in complex organizational structures.

Modern enterprises frequently use detailed department names that include geographical indicators, functional descriptions, and organizational hierarchy information (e.g. North America Sales Operations - Enterprise Accounts - Financial Services Vertical). The expanded character limit ensures these comprehensive naming conventions can be captured without truncation.

Group Name Character Limit

The character limit for Group names has been increased to accommodate 75 characters, providing administrators with greater flexibility in creating descriptive group names.

In cases where group names exceed typical display space, the UI may render only the first 30 characters in list views to maintain layout integrity. However, the complete name is visible on hover, ensuring users can always verify the full group identity before making selections or assignments.

Custom Roles Configurability

A custom role management capability has been introduced, enabling administrators to create granular, company-specific roles that match organizational access requirements and security policies.

A new 'Role' menu is now available under the Foundation module, providing a centralized interface where administrators can view all system roles and create new custom roles tailored to specific company needs, workflows, and compliance requirements.

Administrators can assign these custom roles to individual users and groups, providing flexible access control that adapts to organizational changes.

Administrators define the user experience by mapping specific Application Menus to custom roles, controlling which modules, services, and capabilities are accessible to users holding each role.

To maintain platform stability and ensure upgrade compatibility, built-in system roles remain read-only. Only custom roles can be edited or deleted.

Comprehensive audit logs capture all Role creation events and track changes to Role Name, Description, and Status.

Beyond menu-level access, Administrators can configure Authorization Rules to define specific data privileges (Read, Write, Delete) for custom roles. These rules enable fine-grained control over which records users can view, modify, or remove based on attributes such as company, department, or category.

Important Notes:

• UI Form Access: If an application menu is associated with a role, it will be available to users having that specific role. However, access to the individual UI forms within these menus must also be configured for the role through UI Builder. This two-level access control (menu + form) ensures comprehensive security.
• Current Scope: Custom roles are currently applicable only to the Knowledge Management module. Access to the following menus is fully functional:
  • Knowledge Articles
  • Knowledge Base
  • Article Type
  • Knowledge Feedback
  • Flagged Articles
  • Feedback Tasks

Scheduled Jobs Configurability

A Scheduled Jobs management interface has been introduced, enabling administrators to view, manage, and create automated processes without requiring backend system access or development resources.

A new 'Scheduled jobs' menu has been added under the Administration module, providing visibility into all product default scheduled jobs and the capability to create new company-specific jobs tailored to unique business requirements.

A 'Run Now' button is available to trigger the job immediately on an ad-hoc basis for testing or responding to urgent operational needs.

This feature enables administrators to automate scenarios including periodic data synchronization, scheduled report generation, automated data cleanup, health checks, batch updates, and time-based workflow triggers.

Company-specific scheduled jobs respect multi-tenant boundaries, ensuring each company's automated processes operate only on their own data.

Parent Visibility for Custom Attributes

Enhanced visibility has been added to the Custom Attributes management interface to help administrators understand and navigate complex attribute structures, particularly for Checklist and Composite attribute types.

A new Parent column is now displayed on the Custom Attributes List View. This column identifies the primary parent attribute under which specific Checklist member attributes or Composite member attributes are defined, making the attribute hierarchy immediately visible.

Search by Parent is enabled, allowing administrators to quickly find all related attribute members belonging to a specific parent attribute.

SCIM Auto-Provisioning for Organizations & Departments

The SCIM (System for Cross-domain Identity Management) user provisioning process has been enhanced to automatically handle missing organizational data during user creation and updates.

Automatic Organization Creation:

When a specified Company does not have an existing Active Organization record, the system now automatically creates one.

Automatic Department Creation:

Similarly, if a corresponding Active Department record is missing for the specified Company and Organization, it is automatically generated.

Smart Record Management:

While multiple records with the same name may exist, the system ensures that only one record remains Active per company at any time.

Keyboard Shortcuts for Faster, Accessible Navigation

Introducing keyboard shortcuts that reduce clicks and navigation steps, improving efficiency, productivity, accessibility, and overall user satisfaction. Users can now perform actions such as saving (for example, using Ctrl + Q instead of scrolling to the Save icon), approving changes, refreshing compliance status, or switching between CI and patch views more quickly using the keyboard, which is especially helpful for power users and those who prefer or require keyboard-driven interaction.

From the portal, users can view all available shortcuts in the My Profile section, with a clear list of mappings for both platforms: on Windows all shortcuts are correctly prefixed with Ctrl, and on macOS they are correctly prefixed with Control, giving the product a more enterprise-grade and efficient feel.​

Set Default Notification Time Zone at Company or Instance Level

This enhancement lets administrators define a preferred time zone for all default notifications at the company or instance level, instead of relying on GMT as a fixed default. By configuring a single baseline time zone, all timestamps in system-generated notifications—across patching, compliance, and change-related alerts—are displayed consistently for users, regardless of their local settings.​

Admins configure this under Settings → Company → System Properties, where they select the time zone in which notifications should be sent. The notification engine then reads this setting and applies it automatically before sending any notifications, ensuring that all outgoing messages use the chosen company-standard time zone.​

This delivers multiple benefits: consistency across the organization, easier governance and auditing (as logs and reports align to one time zone), a better end-user experience with no manual time conversion, and more effective planning and management of change windows and other time-bound activities.​

Branded Notification Borders and Footers

This enhancement lets you align system notifications with your organization’s branding by automatically applying the primary brand color to the notification border and footer. Once configured, notifications across the product inherit this color, delivering a more consistent and professional look that clearly reflects your brand rather than a generic system style.​

Admins enable this by navigating to Brand Management from the main navigation and selecting the Primary color according to corporate brand guidelines; notifications then automatically pick up this color for their header and footer areas. Key benefits include stronger brand consistency, a more polished interface, better user recognition of in-product notifications versus external alerts, improved engagement with important messages, and easier adherence to enterprise governance and design standards.​

Restrict data dictionary access for Rules Admin and Administrator roles

To ensure data integrity and configuration safety by restricting modification of Data Dictionary entries (specifically TOT and TOA attributes) to only Super Admins, while allowing Rules Admins and Administrators to view the content they need for reference and rule configuration.

Functional Process as per roles

• Rules Admin & Administrator
  • Can navigate to the Data Dictionary list page.
  • Can search, filter, and open records in the right panel (or equivalent read-only view).
  • Cannot see any Edit icon/link/button.
  • Cannot open the full edit page for any Data Dictionary entry.
  • Have read‑only access for both TOT and TOA records.
• Super Admin
  • Have full create / edit / view access to the Data Dictionary.
  • Can edit default TOT and TOA attributes.
  • Can create new Data Dictionary entries where permitted by existing platform rules.

View-only List Access for Rules Admin and Administrator

• Description: Rules Admin and Administrator roles shall have view-only access to the Data Dictionary list page.
• Details:
  • They can see all records they are currently allowed to see (e.g., TOT, TOA).
  • They can apply filters/search as per existing behavior (read-only operations).

Refer Screenshot from Administrator and Rules Admin(TOT)

Refer Screenshot from Administrator and Rules Admin(TOA):

Refer Screenshot from Super Admin:

Custom attributes Label Length Increased to 250 Characters

Here we have increased the character limit for custom attribute labels, also referred to as custom attribute questions, from 50 characters to 250 characters. The limit increase will be implemented at the foundation level, but corresponding UI improvements are required so long labels remain readable and user-friendly across all Work Item pages.

The main focus of this requirement is the Support user experience while adding, selecting, viewing, and saving custom attributes with long labels on Work Items.

Foundation Requirements

• Increase custom attribute label character limit from 50 to 250 characters.
• Ensure validation, storage, and retrieval support the expanded label size.

UI Behavior on WIB

While Adding Custom Attributes

• The dropdown or selection control supports display of longer custom attribute questions via Tool Tip

• The tool tip allows users to easily view and distinguish long questions during selection.

• If the question exceeds the single-line visible area, the text is truncated with ellipsis after the fixed number of characters that fit in one row.

Once Selected

• The Custom attribute label gets truncated with ellipsis in a controlled and consistent manner.

After Save on Work Item Pages

• Long custom attribute questions renders cleanly on all Work Item pages.
• Truncation with three dots should be used where a one-line fixed area is required.
• A tooltip is available so the support user can access the complete question text after saving.

Edit Custom attributes also displays the tooltip on Custom attribute label selected :