1. Separate identity, authentication and authorisation
An identity provider maintains digital identities and can provide a central sign-in service. Authentication checks that someone is who they claim to be, using credentials, passkeys or other factors. Authorisation determines what that authenticated person may see or do. Successful authentication does not mean unrestricted access.
These distinctions matter operationally: a disabled sign-in method, a removed application assignment and a revoked administrative role are different changes. A reliable access process names the intended outcome, identifies which system controls it and checks the resulting state rather than treating every change as account removal.
- For each important application, record who authenticates users and where permissions are actually controlled.
2. Manage the lifecycle, not just the login
User lifecycle management covers creating, changing, suspending and retiring identities as working relationships change. Application assignments connect people or groups to services; they do not necessarily describe every permission inside those services. A licence provides entitlement to use a product but is not, by itself, proof of current access.
Privileged access concerns elevated capabilities such as administering a tenant or changing security settings. Treat it separately from ordinary application use, with explicit ownership and approval. Otherwise, a routine department transfer can leave someone with both old administrative powers and new business access.
- Keep privileged roles, application assignments and licence allocations distinguishable in reviews.
3. Connect identity information to operational records
An account becomes more useful operationally when linked to an employee, manager, department, device and application owner. These relationships help teams answer who should approve access, whether a departed employee still has assigned equipment and which budget owns a licence.
Use stable identifiers where available, and review ambiguous matches rather than relying only on names or email addresses. Contractors, shared accounts and employees with multiple accounts need explicit treatment. Record the source and freshness of information: an imported account status and a manager-confirmed business need answer different questions.
- Assign an owner to unmatched accounts and conflicting employment or assignment records.
4. Run reviews and offboarding as distinct controls
Access reviews periodically test whether access remains necessary and appropriately scoped. Employee offboarding responds to a specific departure and usually requires coordinated revocation, equipment recovery and ownership transfer. Neither process should assume that removing a central identity automatically closes every application session or locally managed account.
For example, a fictional employee moves from finance to sales. Their identity remains active, but finance approvals and privileged reporting access need review. Sales applications may require new assignments, while documents and recurring responsibilities need new owners. Merely changing the department field would leave the access transition incomplete.
- Record reviewer decisions, exceptions, responsible owners and confirmation of the resulting access state.
5. Understand Lojycal’s role and integration boundaries
Lojycal connects workplace records and workflows, with identity integration capabilities and role-restricted operations. Its own MFA, passkeys and tenant-scoped access controls do not establish that connected applications enforce equivalent controls.
For Microsoft Entra ID, Okta and Google Workspace, confirm current connector availability and supported operations for your plan and workspace. Do not assume equivalent reading, provisioning, group management or revocation capabilities across providers. A supported integration is not evidence of a configured connection; credentials, permissions, mappings and organisational roles affect what can run.
- Ask which identity objects are read, which actions are supported and how each outcome is verified.
6. Evaluate with a bounded access scenario
Start with one employee population and a small application set. Document the authoritative employment source, identity ownership and approval rules before enabling changes. Test account matching and review the permissions required by each connection.
Use an authorised test scenario to trace a role change from request through approval to the destination system. Check that unsupported actions become visible manual tasks rather than apparently completed work. Evaluate exception handling as carefully as the successful path.
- Check behaviour for unmatched identities, insufficient permissions and stale records.
- Confirm supported scope for your workspace and compare plans at /pricing before committing.