Skip to main content

Boxcurve Unity: Secure Configuration Guidance

This guide explains how to configure Boxcurve Unity securely once it is running in your own Microsoft 365 tenant. It is written for your security and platform-administration teams.

How responsibility is shared​

Securing Boxcurve Unity is a shared responsibility across three layers. Understanding which layer owns which control is the foundation of this guide.

  1. The Microsoft platform layer. Boxcurve Unity runs on Microsoft Power Platform and Microsoft Dataverse, and authenticates users through Microsoft Entra ID. The security, availability and integrity of those services are Microsoft's responsibility.
  2. The Boxcurve Unity product layer. Boxcurve provides the application, its built-in security roles, the data scoping it applies, and the controls it places around sensitive actions. These are described below as configurable in this product (verified).
  3. The customer configuration layer, the focus of this guide. You configure and operate the controls around Boxcurve Unity in your tenant: who may sign in and under what conditions, which connectors are permitted, how data is classified, which roles each person holds, and how the hosting environment is governed. Most of the hardening you can do sits at this layer.

This document concentrates on the customer configuration layer. Where a control belongs to the Microsoft platform layer it is labelled platform behaviour, with a pointer to Microsoft's official documentation rather than an explanation. Throughout, two kinds of guidance are kept separate:

  • Configurable in this product (verified), settings, roles and behaviours that Boxcurve Unity actually provides and that your administrators control directly.
  • Recommended operational practice, advice on how to operate those capabilities securely. These are recommendations, not product features.

Attack surface​

Boxcurve Unity is built entirely from in-tenant Power Platform components: a Power App, Dataverse tables, and cloud flows. It contains no custom code, no plug-in assemblies, no custom code controls, and no bespoke .NET or JavaScript. The application therefore adds no custom executable attack surface of its own. The security posture of a Boxcurve Unity deployment is determined chiefly by how you configure your tenant and the hosting environment around it.

For that reason, the strongest controls available to you are the platform and environment controls covered in this guide, Conditional Access, data loss prevention, sensitivity labelling, least-privilege role assignment and environment governance, rather than application-level hardening.

Configurable in this product (verified)​

Boxcurve Unity ships with a set of built-in security roles that form a deliberate least-privilege gradient: each role grants progressively fewer permissions than the one above it. In the application these roles carry a "RACI" prefix, for example, the Administrator role appears as RACI Administrator.

RoleIntended forRelative access
RACI AdministratorApplication administratorsBroadest, full access to all Unity data and administrative actions
RACI Ops ManagerOperations managersBroad data access; fewer administrative actions than Administrator
RACI Project ManagerProject managersProject-scoped access to accountability-map, task, jurisdiction and stakeholder data
RACI Team ManagerTeam managersNarrower, mostly project-scoped access
RACI UserStandard end usersNarrowest, limited to the records a user needs to do their own work

These roles are part of the product. Their permissions are pre-defined and are not designed to be edited; assign the role that matches a person's job rather than modifying the roles themselves.

The least-privilege design is visible in how each role can read and change Unity's business data:

  • The RACI User role does not grant permission to delete the core accountability-map, task, jurisdiction or stakeholder records. Standard users can work with their own tasks and comments but cannot remove shared project data.
  • The RACI Project Manager and RACI Team Manager roles work largely at a project-scoped level for the accountability-map, task and stakeholder records, rather than across the whole environment. A project manager's reach is concentrated on the projects they are responsible for.
  • The RACI Ops Manager and RACI Administrator roles operate across the environment and can delete the core business records; the Administrator role additionally carries the broadest set of administrative permissions.

In addition to these Dataverse security roles, Boxcurve Unity recognises application roles that are evaluated inside the app when a user signs in, for example, Administrator, Operations Manager, Team Member and Stakeholder. These application roles determine which screens and actions a user is offered. Project roles are assigned to users from within the app's Settings screen.

  • Assign the lowest role that lets each person do their job. Reserve the Administrator role for the small number of staff who genuinely administer the application.
  • Keep the built-in roles unmodified. Because the roles are designed as a tiered, least-privilege set, prefer assigning a different role over widening an existing one.
  • Separate duties. Avoid giving a single person both broad data-administration rights and the ability to manage who else has access, unless your governance model requires it.
  • Review the application roles as well as the security roles. A person's effective experience in Boxcurve Unity is shaped by both, so review them together.

2. Scoping who sees which information​

Configurable in this product (verified)​

Boxcurve Unity controls visibility in two complementary ways.

Stakeholder-based access. When a user opens the app, Boxcurve Unity checks whether that user appears in the project's stakeholder list. A user who is not on the stakeholder list is shown a "Not in stakeholder list" message and is not taken into the application's working screens. Membership of the stakeholder list is therefore the practical gate for everyday access, and it is data you control.

Role-scoped data. As described in Section 1, the Project Manager and Team Manager roles are scoped so that a user works primarily with the records belonging to their own projects rather than every project in the environment. This narrows what a given person can see and change to the projects relevant to them.

  • Treat the stakeholder list as an access list. Keep it current: add people when they join a project and remove them when they leave, so visibility tracks real membership.
  • Use project-scoped roles to limit cross-project visibility. Assign Project Manager and Team Manager roles deliberately so that managers see their own projects rather than the whole environment.
  • Periodically reconcile the stakeholder list and assigned roles against your HR or joiner/mover/leaver process.

3. Controls around sensitive actions​

Configurable in this product (verified)​

Boxcurve Unity restricts its most sensitive actions to administrators.

Initial installation is restricted to System Administrators. The first-time setup of the application can only be performed by a user who holds the System Administrator role in the environment. A user without that role is shown a screen stating that only System Administrators are authorised to perform the initial installation, together with the list of the current System Administrators. This prevents an ordinary user from running the one-time setup.

Administrative project operations are grouped behind an administration area. Higher-privilege project lifecycle operations, such as copying, resetting, backing up, restoring and deleting projects, are part of the administrative capability set rather than the standard user experience. The ability to remove the core accountability-map, task and stakeholder records is carried only by the higher roles (Operations Manager and Administrator), not by the standard User role.

Role and access management is itself an administrative action. Assigning and removing roles, and adding or removing users, are administrative functions surfaced through the app's Settings and administration screens rather than to every user.

  • Limit who holds the System Administrator role in the environment that hosts Boxcurve Unity, since that role governs initial installation. Management of the System Administrator role is platform behaviour, see Section 7.
  • Restrict the Administrator role so that destructive project operations (delete, reset, restore) are available only to trusted administrators.
  • Require a second person to authorise irreversible operations such as deleting or resetting a project, as a matter of process.

4. Securing integration connections​

Configurable in this product (verified)​

Boxcurve Unity connects to a number of Microsoft 365 and external services to do its work. Knowing exactly which connections it uses lets you write a precise data loss prevention policy and review data egress. The connections it uses are:

Microsoft 365 / Power Platform connections (in-tenant):

  • Microsoft Dataverse, the application's own data store.
  • Office 365 Users, used to resolve user details.
  • Microsoft 365 Groups, used when Boxcurve Unity manages group ownership for higher-privilege roles.
  • Microsoft Planner, used to create and synchronise tasks.
  • Microsoft OneDrive for Business, used to export task data to a file.
  • Office 365 Outlook, used for email notifications.
  • Microsoft Teams, used for Teams-based notifications and related actions.

External integration connection:

  • Azure DevOps (Visual Studio Team Services), used to create tasks on a DevOps board, through a Microsoft-published connector that runs under credentials your administrator provides.

Optional, customer-configured in-flow integrations. These are not Power Platform connectors; they are direct calls made from within Boxcurve Unity's flows, and they activate only when a user supplies the relevant credential at the point of use:

  • monday.com, when a user chooses to pull tasks from a monday.com board, the user supplies their own monday.com API key, which Boxcurve Unity uses to call the monday.com service. The key is provided per use rather than stored as a tenant connection.
  • Boxcurve's task pack repository, when a user imports a task pack, Boxcurve Unity reads a published list of task packs from Boxcurve's task pack repository, using an access token. This is a read-only download of reference content.

One built-in outbound call to Boxcurve. Separately from the integrations above, Boxcurve Unity makes a single built-in outbound call to a Boxcurve licensing service to retrieve plan and product-notification information. This call sends your tenant identifier, your environment identifier, and an aggregate count of stakeholder maps per plan, it does not send the contents of your project, task or stakeholder records. The call is used for licensing and product notifications only; it does not act as a gate on whether your users can access the application, so a failure of this call does not block access.

Each Microsoft 365 and Azure DevOps connection runs under credentials that your administrators provide and consent to in your tenant, and connections are configured per environment.

  • Use dedicated, least-privilege accounts for the Microsoft 365 and Azure DevOps connections wherever your governance allows, rather than a personal administrator account, so that the application's access is scoped and auditable.
  • Only enable the integrations you use. If your organisation does not use Azure DevOps, monday.com, the Boxcurve task-pack import or Planner, do not establish or use those integrations.
  • Decide deliberately about the optional external integrations. Because monday.com and the Boxcurve task-pack import are reached by direct outbound calls rather than governed connectors, treat them as deliberate egress and ingress decisions. If your policy is to disallow them, you can prevent the use of arbitrary outbound HTTP and the relevant connectors at the Power Platform level (see the next point). The monday.com and task-pack credentials are supplied by the user at the point of use, so they are only as trustworthy as the account that supplies them, issue and scope those credentials accordingly.
  • Govern which connectors are permitted in the environment. Data loss prevention (DLP) policies, which determine whether connectors such as Azure DevOps may be combined with business-data connectors, and whether outbound HTTP is allowed at all, are platform behaviour configured at the Power Platform level, not within Boxcurve Unity. Because Boxcurve Unity's connectors are listed above, you can build a DLP policy that permits exactly the connectors it needs and restricts the rest. See Microsoft's documentation: https://learn.microsoft.com/power-platform/admin/wp-data-loss-prevention
  • Treat the external integrations and the Boxcurve licensing call as data egress points and include them in your data-flow reviews.

5. Data classification and sensitivity labelling​

Boxcurve Unity stores its data in Microsoft Dataverse within your tenant. Classifying and labelling that data is a platform behaviour you configure, not a feature of Boxcurve Unity. Applying Microsoft Purview sensitivity labels and data classification to the data held by Boxcurve Unity lets you bring it under the same protection and governance as the rest of your Microsoft 365 estate.

  • Classify the data Boxcurve Unity holds as part of your information-protection programme. The Data Held & Handling document sets out what Boxcurve Unity stores and can serve as your inventory.
  • Apply Microsoft Purview sensitivity labels and policies to the hosting environment in line with your classification. Sensitivity labelling and classification are configured in Microsoft Purview and Power Platform, not in Boxcurve Unity. See Microsoft's documentation: https://learn.microsoft.com/purview/ and https://learn.microsoft.com/power-platform/admin/wp-security

These recommended practices use the product capabilities described above. They are not automated by Boxcurve Unity unless stated.

  • Review role assignments on a regular cadence. Confirm that each person still needs the role they hold, and that the Administrator role remains restricted to a small, named group.
  • Review the stakeholder list per project. Because stakeholder membership gates everyday access (Section 2), reconcile each project's stakeholder list against current team membership.
  • Review the System Administrators of the environment, since that role controls installation and the broadest platform-level actions.
  • Review active connections and integration credentials for the integrations in Section 4: who owns each Microsoft 365 and Azure DevOps connection, what account it runs as, whether each is still required, and who has been issued monday.com or task-pack credentials for the optional integrations.
  • Tie reviews to joiner/mover/leaver events so that access is removed promptly when people change roles or leave.

7. Platform-provided controls (reference)​

The following protections apply to Boxcurve Unity but are configured in the underlying Microsoft platform, not within the application. They are listed here so your security team knows where responsibility sits.

For how Boxcurve Unity itself uses these services, see the Identity & Access Control, Integrations & Connections, and Administrator Guide documents.