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.

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.​