For IT & Identity Teams

inFM Integration: Work With Your IT Environment

A practical overview of deploying inFM alongside your existing HR, Microsoft Entra ID and facilities processes, with clear ownership of identity, access and application configuration.

Discuss your IT requirements
IT integration overview

Start with the systems your organisation already runs

Facilities software should fit into established IT operations rather than create a parallel identity process. A practical inFM setup can use Microsoft Entra ID for single sign-on, your existing HR-to-directory process as the source of identity attributes, and Entra security groups to connect authorised user cohorts to application roles and facilities locations.

The important distinction is ownership: HR and IT continue to manage people, identity records, directory attributes and group rules. inFM uses the resulting sign-in and group membership information to establish an application account and apply the configured inFM access. It does not replace HRIS, Active Directory or Entra provisioning.

A familiar HR-to-access lifecycle

1. HR / HRISAuthoritative employment and organisational attributes.
2. Identity provisioningYour existing process updates directory accounts and attributes.
3. Entra security groupsStatic or dynamic group rules define relevant user cohorts.
4. inFM sign-inSSO checks group membership and applies configured access.

For example, an organisation may maintain HR-fed department, job-title or office-location attributes in Entra. Entra dynamic group rules can use those attributes to determine group membership. An administrator then maps the relevant security group to an inFM role and, where needed, a Domain, Region, Site or Building. inFM evaluates group membership at sign-in; it does not read HR attributes such as department or job title directly.

What IT configures, and what inFM does

Your identity and infrastructure teams remain in control

inFM consumes the configured sign-in and mappings

Map access to the way facilities teams work

inFM's location hierarchy is Domain, Region, Site, Building and Floor or Space. A broad group can be mapped to a role, while a more specific group can be mapped to a facilities location. This lets identity teams manage membership in Entra and application administrators connect the group to the corresponding inFM scope.

If a person matches multiple mapped groups, inFM uses the highest-priority mapped role and combines location assignments from matching scoped groups. A selected Domain, Region or Site includes its descendant Buildings; selecting a Building grants that Building. These assignments narrow the Building choices in job reporting and are also checked by the API when a job is created.

Know the boundary of location scoping.

Building assignments are not a global filter on every inFM screen; other data visibility follows the existing role and Domain scoping. Validate the specific user experience and reporting workflows your organisation intends to use.

Plan admission and least privilege deliberately

Group-to-role mappings are access grants, not an admission deny-list. Where no location-scoped mappings are configured, an eligible user without a matching group mapping may still be created as a Viewer with front-end access. If only assigned Entra users or groups should sign in, configure Entra enterprise-application assignment restrictions as well as inFM's allowed email domains.

A dynamic group can automatically grant its mapped role when membership changes; inFM does not request per-user approval for each automatic grant. Start with minimum permissions, keep administrator groups tightly controlled, and test membership rules with representative accounts. If any location-scoped mappings are used, every SSO user must match at least one scoped group; role-only mappings do not grant a location and cannot meet that requirement by themselves.

What to expect when people or roles change

inFM evaluates mapped Entra membership when a user signs in. Group, role and location changes are not a continuous background synchronisation and do not immediately revoke an existing session. Removing someone from a group also does not disable their Entra account. Keep account disablement, session handling and access review in your established offboarding process, and test how your tenant's dynamic membership timing affects access changes.

The current Microsoft membership lookup uses the signed-in user's direct /me/memberOf results. Do not assume nested group membership is included; test the actual group structure used in your tenant. For front-end-only cohorts, verify the exact issue-submission and reporting flows they need before broad rollout.

A measured deployment path

  1. Agree ownership. Identify the HR, identity, network, hosting, facilities and application administrators responsible for each part of the service.
  2. Prepare the location model. Agree how Domains, Regions, Sites and Buildings represent the organisation. Review and clean location data before importing it.
  3. Configure and protect SSO. Set the required SSO provider, client ID, server-side client secret, authentication and token URLs, and exact redirect URI. Keep the secret in server environment configuration, not in client-side settings.
  4. Pilot least-privilege groups. Test a small user cohort, a separate administrator group, email-domain restrictions and Entra enterprise-application assignment restrictions.
  5. Test outcomes, not just sign-in. Verify first-login account creation, existing-user matching, role selection, scoped and unscoped groups, allowed and denied Buildings, job submissions, reporting, and leaver procedures.
  6. Document the runbook. Record who changes group rules, inFM mappings, location data, SSO secrets and access policy, and how changes are reviewed.

A low-friction deployment for IT

inFM can be deployed on infrastructure selected by your organisation, including Docker or Windows Server/IIS environments. Users access the application through a web browser, so there is no separate desktop client to package and roll out. With SSO enabled, a user's first successful sign-in can create their inFM account; IT can continue to manage identity and group membership through its existing Entra processes.

Microsoft Entra SSO requires the configured identity endpoints and, for group mapping, connectivity for the Microsoft Graph membership lookup. A restricted or offline environment should be assessed against its own identity and network requirements before selecting an authentication model.

For a detailed configuration checklist, see the inFM IT Administration Guide. For hosting choices, see the self-hosted CMMS overview.

Related guides

Want to evaluate the fit with your environment?

Share your hosting, identity and facilities requirements with the inFM team.

Talk to inFM