Boxcurve Unity: Identity & Access Control

This document describes how people sign in to Boxcurve Unity, how the application identifies them, and how their access to features and data is controlled. It is written for your security architects and identity administrators, and covers both what Boxcurve Unity provides and what your organisation configures inside your own Microsoft 365 tenant.

Boxcurve Unity helps you map operational processes and accountability across your projects and operations. Its central feature is the accountability map, a grid that records who holds each responsibility for the work you track. The application runs as a Power Platform application (backed by Microsoft Dataverse) inside your tenant. It contains no custom code components, plug-ins or bespoke authentication of its own.

Shared responsibility at a glance

Identity and access control for Boxcurve Unity are divided across three layers. Keeping these layers distinct is the simplest way for a reviewer to see where a given control is owned and enforced.

• The Microsoft platform layer. Microsoft Entra ID and Power Platform provide sign-in, multi-factor authentication, conditional access, token issuance, session handling and the Dataverse security model. Boxcurve Unity relies on this layer and inherits its controls; it does not implement or replace any of them.
• The Boxcurve Unity layer. Boxcurve Unity defines five application roles and the in-application logic that decides who may enter the application and which administrative areas they may use. This is the part Boxcurve Unity supplies and this document describes in detail.
• Your configuration layer. Your organisation decides who is assigned each role, who is a stakeholder on each project, and how the platform controls above (MFA, conditional access, account lifecycle) are configured for your tenant.

Sign-in and identity

Boxcurve Unity does not have its own username-and-password system. Users sign in with their existing organisational Microsoft account, and the application receives their verified identity from the Microsoft platform.

When a user opens Boxcurve Unity, the application reads the signed-in user's identity, their organisational email address and their Microsoft Entra ID object identifier, from the platform, and uses that identity to determine what they are allowed to see and do. No separate Boxcurve Unity credential is created or stored.

Platform responsibility

Sign-in, multi-factor authentication, conditional access, token issuance and session handling are provided by Microsoft Entra ID and Power Platform, not by Boxcurve Unity. Because Boxcurve Unity is a Power Platform application that uses your tenant's identity, any sign-in controls you enforce in Entra ID, for example requiring MFA or restricting access by location or device, apply to Boxcurve Unity at sign-in without any application-specific configuration. Boxcurve Unity does not weaken, bypass or re-implement these controls.

• Microsoft Entra ID sign-in and access controls: https://learn.microsoft.com/entra/identity/
• Securing access to Power Platform applications: https://learn.microsoft.com/power-platform/admin/wp-security

How the application connects to data and services

Boxcurve Unity does not use a bespoke Microsoft Entra application registration with its own OAuth consent scopes. Instead, the application and its background processes connect to Dataverse and to the other Microsoft 365 services they use through standard Microsoft connectors, established as named connections when the application is deployed and owned by an identity in your tenant. Boxcurve Unity uses a small, fixed set of Microsoft connectors, covering Dataverse, Microsoft 365 mail and calendars, Microsoft 365 groups and users, OneDrive, Planner, Microsoft Teams and Azure DevOps.

For a reviewer, the practical consequences are:

• There is no separate consent surface or third-party application identity to assess for Boxcurve Unity beyond the standard Microsoft connectors it uses.
• The access available to a connection is the access held by the account that owns it, combined with the permissions of the connector in use. Reviewing and governing those connections is part of your Power Platform administration.

Platform responsibility

How connectors and connections are governed, shared and secured is a function of the Microsoft Power Platform, not of Boxcurve Unity. See Microsoft's documentation: https://learn.microsoft.com/power-platform/admin/wp-security

Identity used by background processes

Several Boxcurve Unity functions are carried out by background processes (automated flows), for example assigning a role to a user, or sending a notification when a task is assigned. These processes are triggered from within the application by the signed-in user and run under the connections established for the application rather than under a distinct service identity defined by Boxcurve Unity. The data each process can reach is therefore governed by the permissions of those connections and by the Dataverse security model described below.

How access is decided when a user opens the app

When a user launches Boxcurve Unity, the application performs a sequence of identity checks before showing any project information. These checks are layered, a user must pass the relevant checks to proceed.

1. Data permission check. The application first confirms that the user has permission to read the stakeholder records that hold project participation. A user without that permission is directed to a message indicating they are not currently part of a stakeholder list.

2. First-time setup check. If the application has not yet been set up in the tenant (no projects or stakeholder records exist), only a user holding the tenant System Administrator role may perform the initial setup. A user without that role who opens an uninitialised application is directed to a screen explaining that they are not a system administrator and cannot complete first-time setup.

3. Stakeholder-membership check. Once the application is set up, a user must also be listed as a participant (a "stakeholder") on a project to be taken into the application. A user who is not on any project's stakeholder list is shown a message indicating they are not currently part of a stakeholder list.

In normal day-to-day use, therefore, a person must be assigned as a stakeholder on at least one project and hold an application role before the application will admit them and show the corresponding features.

Roles available in Boxcurve Unity

Boxcurve Unity defines five application roles, described below by their function:

• Administrator
• Operations Manager
• Project Manager
• Team Manager
• User

Note

In the application these roles are currently labelled with a "RACI" prefix, for example the Administrator role appears as RACI Administrator. The functional names used in this document map directly to those in-application labels. Each application role corresponds to a dedicated Microsoft 365 security group, and to a Dataverse security role of the matching name, all held within your tenant. The application determines a user's role from their membership of the corresponding group, while the Dataverse security roles govern the underlying data permissions.

Each role grants a different level of access to the information Boxcurve Unity manages, projects, stakeholders, accountability maps, tasks, categories, departments, jurisdictions, task packs, comments, notifications, change-log records and application settings. The roles form a graduated hierarchy: Administrator is the broadest, and User is the most limited.

The descriptions below summarise what each role can do within the application, based on the access each role is granted to Boxcurve Unity's data.

Administrator

The most capable role. An Administrator can work with the full set of Boxcurve Unity information across all projects, including the records that define how the application is configured. In addition to project, stakeholder, task and accountability-map records, this role can create and manage the application's own settings and plan/licence-related records, configuration data that the other roles cannot create. The Administrator and Operations Manager are the roles permitted to manage who has access (see Managing access).

Operations Manager

A broad operational role. An Operations Manager can work across projects, stakeholders, accountability maps, tasks, categories, departments, jurisdictions, task packs, comments, notifications and change-log records, in much the same way as an Administrator for day-to-day operations. The main difference is that this role does not create the application's own settings or plan/licence records. Together with the Administrator, this role is permitted to manage who has access.

Project Manager

A project-level management role. A Project Manager can create and work with the core project content, stakeholders, accountability maps, tasks, categories, departments, jurisdictions, task packs, comments, notifications and change-log records. Compared with the Operations Manager, some of this role's create permissions are granted at a narrower (project-level) scope rather than across the whole organisation. This role does not create the application's settings records.

Team Manager

A team-level role with a narrower scope than Project Manager. A Team Manager can work with stakeholders, accountability maps, tasks, departments, task packs, comments, notifications and change-log records, and creates accountability-map and task-pack content at a project-level scope. This role is not granted the ability to create some of the broader reference data, for example, categories and jurisdictions, that the project- and operations-level roles can create.

User

The most limited role, intended for everyday participants. A User can interact with their own assignments and contribute content such as comments and notifications, and the application records their activity in change logs. This role is not granted the ability to create the project-defining records (projects, stakeholders, accountability maps, categories, departments, jurisdictions or task packs) that the management roles can.

How to read these descriptions

The differences above reflect the access each role is granted to Boxcurve Unity's data, including the scope at which each permission applies (for example, organisation-wide versus project-level). The exact set of actions a given user can perform also depends on Dataverse security and on which projects they are a stakeholder of, as described in the next section.

How access is enforced

Access in Boxcurve Unity is enforced by two complementary mechanisms working together inside your tenant:

• Dataverse security. Each Boxcurve Unity role has a matching Dataverse security role that grants specific permissions (create, read, write, append, share and so on) over the application's data tables, each at a defined scope. A user can only perform an action if the role assigned to them permits it at the required scope. This enforcement happens at the data layer, so it applies regardless of how the data is accessed.

• The Boxcurve Unity application logic. On top of the data permissions, the application itself adjusts what each user sees and can do. It determines each user's application role from their membership of the corresponding Microsoft 365 security group, decides at start-up whether to admit the user at all (the layered checks described above), and limits certain administrative functions, such as the team-member and role-assignment area, to users holding the Administrator or Operations Manager roles, presenting a view-only experience to everyone else.

Because the underlying data permissions are enforced by Dataverse, the role model is not purely cosmetic: a user without the required permissions cannot reach the corresponding data even if a part of the interface were reached.

Platform responsibility

The Dataverse security model itself (how security roles, business units, record ownership and permission scopes work) and Microsoft 365 group membership are part of the Microsoft platform. Boxcurve Unity uses these models; it does not change how they work. See Microsoft's documentation: https://learn.microsoft.com/power-platform/admin/wp-security

Managing access

Access to Boxcurve Unity is managed from within the application by suitably privileged users. The role-assignment and team-member areas of the application are editable only by users holding the Administrator or Operations Manager roles; other users see these areas in read-only form.

When an administrator assigns a person a Boxcurve Unity role through the application, a background process updates the membership of the Microsoft 365 security group for that role and the related records in Dataverse, so the person gains the access to Boxcurve Unity that goes with the role. Removing or changing a person's role updates that membership and changes their access accordingly. These changes are made within your own tenant; no identity data leaves your Microsoft 365 environment as part of role assignment.

During the initial setup of Boxcurve Unity in a tenant, the first set of administrators, operations managers and users is established as part of the first-install process, which can only be carried out by a user holding the tenant System Administrator role.

Platform responsibility

Creating and disabling the underlying user accounts, and managing organisation-wide identity and group membership, remain functions of Microsoft Entra ID and the Power Platform administration experience in your tenant, not of Boxcurve Unity. See: https://learn.microsoft.com/entra/identity/

Holding more than one role

A person can be granted more than one Boxcurve Unity role. The roles are graduated rather than mutually exclusive, so when a user holds several roles, their effective access is the combination of what those roles allow. For example, the application treats a user as able to manage role assignments if either the Administrator or the Operations Manager role applies to them. There is no separate conflict-resolution behaviour beyond this combined effect.

Summary of responsibilities

Area	Provided by Boxcurve Unity	Your organisation's responsibility
User sign-in / authentication	Relies on the platform; implements none of its own	Configure Microsoft Entra ID sign-in, MFA and conditional access
User accounts and lifecycle	Not provided	Create, manage and disable accounts in your tenant
Connections to data and services	Uses standard Microsoft connectors	Govern, own and review those connections
Application roles (the five roles)	Defined and enforced via Microsoft 365 groups and matching Dataverse security roles	Decide who is assigned each role
Assigning Boxcurve Unity roles	In-app, by Administrator / Operations Manager	Operate this process and keep assignments current
Stakeholder membership per project	Defined and enforced	Maintain each project's stakeholder list
Initial setup (first install)	Provided, restricted to a System Administrator	Have a System Administrator perform first install

Note

Boxcurve Unity does not include any artificial-intelligence feature that affects identity or access decisions; access is determined solely by the role model and Dataverse security described in this document.