Boxcurve Unity: Incident Handling & Escalation

This document describes how Boxcurve Unity behaves when an operation fails, what information it records to support an investigation, how to raise an incident with Boxcurve, and where responsibility sits between you, Boxcurve, and the underlying Microsoft platform. It is written for the IT support and operations teams who run Boxcurve Unity inside your own Microsoft 365 tenant.

The behaviours described here are those built into the application. Incident severity classifications, target response and resolution times, named support contacts, and hours of cover are agreed separately by licence level and are not fixed within the product, see Service commitments and contacts.

Shared responsibility for incidents

Incident handling for Boxcurve Unity is shared across three parties:

• Microsoft operates the underlying Power Platform and Microsoft 365 services. Availability of those platforms, and incidents that originate within them, are handled by Microsoft and surfaced through the Microsoft administration and service-health tooling that you operate.
• Boxcurve is responsible for the Boxcurve Unity application itself: investigating and resolving defects in the app, and notifying you of a confirmed personal-data breach (see The 72-hour breach-notification commitment).
• You, the customer, operate Boxcurve Unity inside your own tenant. First-line operation, triage, and your own internal incident-response process sit with your IT support and operations teams.

Boxcurve Unity is an entirely in-tenant Power Platform application. It contains no custom code, and it runs on your data within your own environment. Boxcurve holds no standing access to your tenant; any access required to help investigate an incident is granted by you, under your support agreement, for the duration of that work.

How the application handles failures

Boxcurve Unity is made up of two parts: the app that users interact with, and a set of background processes that carry out longer-running or multi-step operations, for example creating a project, assigning roles, importing or exporting tasks, and synchronising tasks with connected services.

Failures are handled in two layers: those that occur in the app screens, and those that occur in the background processes.

Failures inside the app screens

If an operation started directly on screen encounters an unexpected error, the application captures it centrally rather than letting it interrupt the user without explanation. A record is written to the application's error log (described below) containing details of where and how the failure occurred.

For specific, expected outcomes, the app also shows the user an on-screen message as it happens, for example a confirmation that an action succeeded, or a notice that it did not. These messages appear in the user's selected language. Whether a message is shown, and its exact wording, depends on the operation being performed.

Failures inside background processes

Background processes follow a consistent failure-handling pattern. Each process runs its main work as a single unit. If any step in that unit fails or times out, a dedicated error-handling stage runs automatically. This stage:

1. identifies which step failed;
2. captures the surrounding context of the failure;
3. writes a record to the application's error log (described below); and
4. ends the process in a failed state, returning the underlying error code and message to the part of the application that started it.

Because the process returns the failure to its caller rather than ending silently, the app can react to the outcome, for example by informing the user that the operation did not complete.

This standardised pattern is applied across Boxcurve Unity's background processes, including those that create and manage projects, assign roles and applications to users, import and export tasks, and synchronise tasks with connected services.

Behaviour when the licensing check is unavailable

When the application starts, it contacts a Boxcurve licensing service to retrieve the plan and licence information associated with your tenant. This check is designed to fail open with respect to access: it does not gate a user's ability to open and use the application.

If the licensing service is unreachable or returns nothing, users are not locked out. The application proceeds with no plan information available, the licence information is empty, and features that depend on a particular plan behave as though no entitlement was returned. Access to the application is determined by the user's membership and access within your own tenant, not by the outcome of this check.

A licensing check that returns no plan is not, in itself, an application fault. If users report that plan-dependent features are unavailable, confirm whether the licensing service was reachable as part of triage before escalating. Connectivity to external services from your tenant is governed by your own environment configuration.

What information is captured to support an investigation

Boxcurve Unity records failures to a dedicated error log held in your own Dataverse environment, inside your Microsoft 365 tenant. The error log is the primary source of evidence for diagnosing an incident.

For each logged failure, the application records the following information where it is available:

Recorded detail	What it tells the investigator
Application module	The part of the application where the failure occurred (for app-screen failures, the screen that was active at the time).
Component	The specific part of the system that failed, for a background process, the name of that process; for app-screen failures, the application name.
Component type	Whether the failure occurred in the app itself or in a background process.
Error code	The error or status code returned, where one was available.
Error message	A short description of the failure.
Error context	Additional contextual detail about the failure, which for background-process failures can include a substantial extract of the underlying error output to aid diagnosis.
User email	The email address of the user who encountered the failure, where applicable.
Environment	The environment in which the failure occurred, to help distinguish issues between deployment stages.
Date and time created	When the failure was recorded.

Each error-log record also carries the standard Dataverse audit fields, who created it and when, and who last modified it and when.

Beyond the error log, Boxcurve Unity captures task change history and other activity for audit and review purposes. This is covered in the separate Activity Logging & Audit Evidence document, and that change history can also serve as supporting evidence during an investigation.

Who can see the error log

Boxcurve Unity surfaces the error log to administrators within the application. The Administration area includes an Error Logs view that lists recorded failures, most recent first, showing the failing component, the affected user, and the time each entry was logged. From the same view, an administrator can clear the error-log entries.

Clearing the error log removes the recorded entries. Where retention of failure evidence is required for your own investigations or compliance, capture or export the relevant entries before clearing. Boxcurve Unity does not define a retention period for error-log entries; retention is governed by your own configuration and operational practices in your Dataverse environment.

Errors a user may encounter directly

In addition to logged failures, Boxcurve Unity presents certain conditions to the user as a dedicated screen rather than as an error:

• A user who opens the app but is not recognised as a system administrator (where the action they attempt requires that level of access) is shown a dedicated screen indicating they do not have the required administrator access.
• A user who is not present in the project's stakeholder list is shown a dedicated screen indicating they are not currently part of that list.

These are expected access conditions rather than faults, so the application does not record them to the error log. They are resolved by an administrator adjusting the user's access, see the Administrator Guide and Identity & Access Control documents.

Sign-in problems, multi-factor authentication prompts, and other identity-related issues are not handled by Boxcurve Unity itself; they are managed by Microsoft Entra ID. For those, see Microsoft's documentation: Microsoft Entra ID documentation.

Detecting an incident

You have several signals available when deciding whether an incident has occurred:

• The error log. Logged application and background-process failures, visible in the Administration area's Error Logs view, are the primary in-app signal that something has gone wrong.
• Task change history. Recorded changes to tasks (see the Activity Logging & Audit Evidence document) can help establish what happened and when, and can corroborate or refine a report.
• Platform monitoring you operate. Service health, sign-in activity, and connector status for the underlying Microsoft platform are surfaced through the Microsoft administration and service-health tooling that you run. Boxcurve Unity does not monitor or report platform health on your behalf.

A confirmed personal-data breach is a distinct category. Where Boxcurve confirms a breach affecting the application, Boxcurve will notify you (see below); where you detect a breach within your own environment, your internal incident-response process and your obligations under your contractual arrangements apply.

Customer responsibilities and how to escalate

Boxcurve Unity runs inside your own Microsoft 365 tenant, so first-line operation and triage of incidents sit with your IT support and operations teams. Escalate to Boxcurve when first-line triage cannot resolve the issue.

First-line response (customer)

When a user reports a problem with Boxcurve Unity:

1. Capture the report. Record what the user was doing, the screen or function involved, the approximate time, and any on-screen message they saw.
2. Check the Error Logs view. Have an administrator open the Administration area's Error Logs view and look for matching entries around the reported time, using the affected component, user email, and timestamp to locate them. Note the error message, error code, and context.
3. Determine the layer. Use the component type recorded against the entry to tell whether the failure occurred in the app or in a background process (see How the application handles failures, above).
4. Check for access conditions. If the user was shown an access screen (not a fault), confirm the user's access and stakeholder-list membership before treating it as an incident, see the Administrator Guide.
5. Check connected services. Where the failed operation involves a connected service (for example task synchronisation or task creation in a connected work-tracking service), confirm the relevant connection is in place and healthy, see the Integrations & Connections document.

Platform-side issues

Some symptoms originate in the underlying Microsoft platform rather than in Boxcurve Unity, for example sign-in failures, Power Platform service availability, or connector outages. These are investigated through the relevant Microsoft administration and service-health tooling. Boxcurve Unity does not manage or report platform health. For Power Platform service health and admin guidance, see Microsoft's documentation: Power Platform admin documentation.

Escalating to Boxcurve

When you escalate to Boxcurve, provide the evidence gathered during first-line triage, in particular the relevant error-log entries (component, error code, error message, context, environment, affected user, and timestamp) and a description of what the user was attempting.

Boxcurve Unity is supported by email. Raise an incident with Boxcurve at [email protected]. Enterprise support agreements, which can define dedicated escalation routes and service commitments, are available on request.

Because Boxcurve holds no standing access to your tenant, any access Boxcurve needs to investigate is granted by you under your support agreement, for that engagement only. The specific escalation route, severity definitions, and target response and resolution times are set by your support agreement and are agreed separately by licence level.

The 72-hour breach-notification commitment

Where Boxcurve confirms a personal-data breach affecting Boxcurve Unity, Boxcurve will notify your nominated contact within 72 hours of confirming the breach.

The contact who receives that notification is identified through your support and contractual arrangements with Boxcurve; ensure your nominated contact details are current. Your own assessment of, and any regulatory notification arising from, a breach within your environment remain governed by your internal incident-response process and your contractual obligations.

Service commitments and contacts

The following are agreed separately by licence level and are not fixed within the product; they are not derived from the application:

• Incident severity definitions and prioritisation.
• Target response and resolution times.
• Named support and escalation contacts beyond the support address above.
• Hours of cover.

These are established through your support and contractual arrangements with Boxcurve. Refer to your applicable support terms for the authoritative values.