Spaarke for Your IT Team: Architecture & Deployment Q&A

Throughout this series, we have covered the strategic rationale for building on Microsoft, the principles of data sovereignty, and the business case for Tenant Dedicated Deployment. Those articles were written primarily for legal operations leaders and executives. This one is different.

This article is written for the IT team that will be asked to evaluate, approve, and support Spaarke. It consolidates the technical architecture, deployment model, security posture, licensing requirements, and operational details into a single reference — the kind of document that shortens evaluation cycles and eliminates the back-and-forth between legal ops and IT.

If you are in legal operations and your IT team has questions about Spaarke, send them this article.

---

Architecture Overview

Spaarke is built entirely on the Microsoft Power Platform and deploys within your organization's own Microsoft 365 tenant. There is no external infrastructure, no vendor-hosted environment, and no data egress.

Here is the technology stack:

• Runtime: Model-driven and canvas apps built on Microsoft Power Apps, running on Dataverse
• Data layer: Microsoft Dataverse — all Spaarke data (matters, invoices, workflows, operational memory) is stored within tables in your tenant's Dataverse environment
• AI layer: Azure AI Foundry (knowledge grounding), Microsoft Copilot Studio (orchestration), and Microsoft Agent Framework (execution), surfaced through Microsoft 365 Copilot. AI capabilities operate within the tenant boundary, grounded in structured legal data stored in Dataverse and SharePoint Embedded
• Document storage: SharePoint Embedded (SPE) — Microsoft's developer-grade SharePoint storage running inside your tenant. Spaarke documents live in their own SPE container, isolated from your existing SharePoint Online sites (no commingling between SPE and SPO). Native versioning, metadata, co-authoring, sensitivity labels, and retention all apply
• Communication: Microsoft Teams and Outlook — notifications, collaboration spaces, calendar integration; email capture at the Exchange layer (so capture is independent of which Outlook client a user prefers)
• Workflow engine: Spaarke's own engine — purpose-built for legal-operations volume and complexity (matter routing, approval chains, OCG enforcement, escalation rules, event-driven execution). Power Automate is not the core platform engine; it sits alongside Spaarke as the customer-extensibility layer
• Customer-extensibility automation: Power Automate — for organization-specific workflows, integration with enterprise systems via Power Platform connectors, and process automation outside the core platform
• Analytics: Power BI — embedded dashboards and executive reporting built on the Dataverse data model. The Dataverse foundation extends natively into Microsoft Fabric workloads as organizations consolidate analytics there — no separate data migration when the analytics center of gravity moves

This architecture means Spaarke is not a separate system that integrates with Microsoft. It is a Microsoft-native application that runs inside your existing environment. The distinction matters: there are no API bridges to maintain, no data synchronization to monitor, and no additional infrastructure to secure.

For the business context behind this architectural decision, see Why We Built on Microsoft and Tenant Dedicated Deployment: The New On-Premises.

---

Deployment Model

Spaarke follows what we call Tenant Dedicated Deployment — a model where the platform runs entirely within your organization's own M365 tenant rather than on vendor-managed infrastructure.

Here is what deployment looks like in practice:

Provisioning. Spaarke is delivered as a managed solution package deployed into your Dataverse environment. Managed solutions are the standard Power Platform mechanism for distributing applications — your team likely already uses them for other business applications. The solution package contains the data model, application components, workflows, and configuration.

Environment strategy. Spaarke supports standard Power Platform environment separation. Most organizations deploy across development, test, and production environments. Solution promotion follows the same ALM (Application Lifecycle Management) practices your team already uses for other Power Platform solutions.

Deployment timeline. Typical deployments complete in weeks, not months. The primary timeline driver is not technical complexity — it is configuration scope. Defining matter taxonomies, workflow rules, security roles, and migration requirements takes longer than the technical deployment itself.

IT responsibilities during deployment:

• Provision the Dataverse environment (or environments, if following a dev/test/prod strategy)
• Assign Power Platform licenses to users
• Configure security roles and access policies
• Review and approve DLP policies for the environment
• Coordinate with Spaarke on any tenant-specific security configurations

Spaarke responsibilities during deployment:

• Deploy and configure the managed solution
• Set up the data model and initial configuration
• Migrate existing data (matter history, spend data, document libraries) where applicable
• Deliver administrator and end-user training

No virtual machines to provision. No databases to administer. No network configurations to design. No vendor servers to include in your penetration testing scope.

---

Security and Compliance

Spaarke inherits your existing Microsoft 365 security posture. This is not a figure of speech — it is an architectural consequence of running inside your tenant.

Identity and access management. Microsoft Entra ID (formerly Azure AD) handles all authentication. Multi-factor authentication requirements, Conditional Access policies, and the user's existing SSO experience apply to Spaarke automatically.

Organizations using a third-party identity provider — Okta, Ping Identity, OneLogin, ADFS, or others — federate to Entra ID through standard SAML or OpenID Connect, and Spaarke inherits whatever IdP configuration is already in place. The user signs in through the IdP they already use; Entra ID handles the federated session; Spaarke sees an authenticated user with the right group membership and security role. There is no separate identity provider for Spaarke, no parallel user directory, and no additional credentials for users to manage.

Data governance. Microsoft Purview extends to all Spaarke data natively. Sensitivity labels, data classification policies, retention rules, and Data Loss Prevention (DLP) configurations that your compliance team has already implemented cover Spaarke data without additional setup.

Role-based access control. Dataverse security roles provide granular access control within the application. You define who can see which matters, approve which invoices, and access which reports — using the same role-based model that governs other Dataverse applications in your environment.

Encryption. Data is encrypted at rest and in transit using Microsoft's standard M365 encryption. Customer-managed encryption keys (CMEK) are supported for organizations that require them.

Audit logging. Spaarke activities are captured in the Microsoft 365 unified audit log and in Dataverse audit tables. Your security team monitors Spaarke activity through the same compliance center and audit tools they already use — no separate logging infrastructure to configure or query.

Compliance certifications. Because Spaarke data resides within your M365 tenant, it is covered by your tenant-level compliance certifications. SOC 2, ISO 27001, HIPAA, FedRAMP, GDPR — whatever certifications your Microsoft environment carries, Spaarke data inherits.

The net effect: there is no additional security perimeter to evaluate. No separate vendor infrastructure to include in your risk assessment. No new attack surface introduced. The security review for Spaarke is a Power Platform solution review, not a full vendor infrastructure assessment.

As we explored in Your Legal Data Belongs to You, data sovereignty is not a policy commitment — it is a structural outcome of where the platform runs. For IT teams, this means the governance model you have already built for Microsoft 365 extends to your legal operations platform without modification.

---

Integration Points

Spaarke's integrations are native to the Microsoft ecosystem, not bolted on through middleware or third-party connectors.

Microsoft 365 Copilot. Spaarke exposes structured legal data — matter history, spend patterns, workflow context, institutional memory — to Copilot. Users can query legal operations data through natural language within Copilot, grounded in structured data that produces far more relevant outputs than Copilot applied to unstructured email and documents alone. All Copilot processing occurs within the tenant boundary.

SharePoint Embedded (SPE). Matter documents are stored in SharePoint Embedded — Microsoft's developer-grade SharePoint storage running inside your tenant. Spaarke uses its own SPE container, isolated from your existing SharePoint Online sites; the two do not commingle. Documents inherit native SharePoint capabilities (versioning, metadata, co-authoring, sensitivity labels, retention) but operational governance is partitioned to the legal-operations workload. No separate DMS to license, deploy, or maintain.

Outlook. Email capture for matter-related correspondence, notification delivery for workflow events, and calendar integration for deadlines and key dates. Users interact with matter data without leaving their inbox.

Teams. Dedicated matter channels, collaboration spaces tied to active matters, and notification bots that surface workflow events and approvals directly in Teams.

Spaarke workflow engine + Power Automate (customer extensibility). Spaarke ships with its own workflow engine purpose-built for legal-operations volume and complexity — matter routing, approval chains, OCG enforcement, escalation rules, and event-driven execution run on the Spaarke engine, not on Power Automate. Power Automate sits alongside as the customer-extensibility layer: your team can build organization-specific workflows that subscribe to matter events and reach into Power Platform's library of standard and custom connectors (ServiceNow, SAP, Salesforce, DocuSign, Workday, and hundreds of others) without modifying the core platform.

Power BI. Embedded analytics and executive dashboards built on the Dataverse data model. Your team can extend or customize reports using the same Power BI tools and skills they already have.

Dataverse Web API + webhooks. A standard REST API for data CRUD, custom integrations, and programmatic access to Spaarke data. Webhooks publish matter events (matter created, status changed, document uploaded, invoice received, OCG flag raised) to subscribed systems for event-driven integration. Same API surface and event model that all Dataverse applications expose — no proprietary interface to learn.

Azure services for advanced integration. For cases that exceed connector-based integration — high-throughput data exchange, asynchronous event flows, custom inference pipelines, or governance over outbound APIs — Spaarke surfaces operate on Azure infrastructure your team already runs: Azure Service Bus and Event Grid for matter-event publishing at scale, Azure Logic Apps and Azure Functions for custom orchestration, Azure API Management for governance over outbound APIs. Spaarke does not require these — connector-based patterns handle most cases — but the option exists, runs on the same Azure subscription that hosts the rest of the customer's infrastructure, and is licensed under the customer's existing Azure agreement.

---

Licensing and Requirements

Transparency on licensing is important. Here is how Spaarke's licensing model works.

Microsoft prerequisites:

• Microsoft 365 E3 or E5 (or equivalent licensing that includes core M365 services). Most enterprise legal departments already have this in place.
• Power Apps licenses: Either per-user licenses (for users who need broad access across the platform) or per-app licenses (for users who only need access to specific Spaarke applications). The right mix depends on the number of users and their access patterns.
• Dataverse storage capacity: Spaarke data resides in Dataverse, which requires storage capacity. The base capacity included with Power Apps licenses is typically sufficient for initial deployment; larger organizations with extensive matter histories may need additional database and file storage capacity.
• Microsoft 365 Copilot licenses (optional): Required for AI features — natural language queries, AI-generated insights, and intelligent search across legal operations data. The core Spaarke platform operates fully without Copilot licenses; AI capabilities are additive, not required.

Spaarke licensing:

Spaarke is licensed on a per-user basis. Licensing includes the managed solution, configuration support, updates, and standard support. Implementation services — data migration, custom configuration, and training — are scoped separately based on organizational requirements.

Specific pricing is determined based on user count, deployment scope, and implementation complexity. Contact Spaarke for a detailed quote aligned to your organization's requirements.

Important note on cost structure. Because Spaarke runs on your existing Microsoft infrastructure, there are no hidden compute costs, no separate hosting fees, and no infrastructure markups. Your Microsoft licensing investment carries the platform — Spaarke licensing covers the application and services layer on top.

AI infrastructure — customer-licensed. Spaarke's AI capabilities — Foundry IQ for grounding and operational memory, the Microsoft Agent Framework for orchestration and execution — run on Azure AI services (Azure AI Foundry, Azure OpenAI Service, Azure AI Search). The user surfaces (Microsoft 365 apps, Power Platform, Microsoft 365 Copilot, Power BI) are licensed through your existing Microsoft 365 and Power Platform agreements. In Tenant Dedicated Deployment, the customer provisions the Azure AI services directly under their own Azure subscription and licenses them through their existing Azure / Enterprise Agreement.

This is a deliberate architectural choice. AI consumption is a line item on the customer's Azure bill — negotiated EA pricing applies, cost-management policies (budgets, alerts, tag-based allocation, reserved capacity for predictable workloads) apply, and model tier / region / capacity selection stay under the customer's control. There is no Spaarke-mediated AI markup, no opaque AI surcharge, and AI cost scales with the customer's actual usage rather than with whatever the vendor decides to bundle. For most enterprise customers, this is significantly cheaper and more transparent than vendor-bundled AI pricing.

---

Data Onboarding

For most organizations, Spaarke is replacing or consolidating systems that already hold legal data. Onboarding is one of the larger questions IT and legal-ops teams have, and the answer depends on what is coming in and what shape it is in.

What typically migrates:

• Matter records from existing ELM, matter-management, or spreadsheet sources — including taxonomy mapping, status, parties, dates, and historical notes.
• Invoice and spend history from e-billing platforms — line-item granularity where available, summarized where not. LEDES files import directly.
• Outside counsel and timekeeper records — firms, panels, rate cards, and OCG history.
• Contracts and matter documents — depending on volume and source-system structure, either migrated into SharePoint Embedded with metadata, or linked in place where the source remains the system of record.
• OCG rules and policies — decoded from the source system (or from PDFs and Word documents) into the configurable rules Spaarke enforces against incoming invoices.

Approach. Spaarke provides import tooling for the standard sources (LEDES, common ELM exports, SharePoint document libraries, Outlook PSTs) and migration services for non-standard cases. Migration runs in phases and stages in a non-production environment first, so the team can verify counts, mappings, and edge cases before promotion to production. Data integrity is validated at each stage.

Documents — migrate or link? A common decision point. For active matter documents, migration into SharePoint Embedded is the default — documents become part of Spaarke's matter context, with versioning preserved and AI grounding intact. For long-archived or large-volume historical document libraries, linkage (Spaarke references the document in place via the relationship graph) often makes more sense than full migration. The right answer depends on access patterns and retention strategy; the implementation plan calls it explicitly.

Timeline. Onboarding typically completes within the deployment timeline (weeks, not months) because the work runs in parallel with configuration. The pacing factor is data quality at the source, not the migration tooling itself.

---

Maintenance and Support

In Tenant Dedicated Deployment, the platform runs in your tenant — which means the operational responsibility split is different from typical SaaS. The line is intentionally clean.

Spaarke's responsibility:

• Maintain the Spaarke managed solution: feature updates, bug fixes, security patches, and platform-compatibility updates.
• Ship updates as managed-solution releases on a published cadence; the customer controls timing of import.
• Provide direct technical support with defined response times by severity (critical: same-day; standard: business-day).
• Operate as the technical escalation path for application-layer issues.

Microsoft's responsibility (inherited):

• Power Platform, Dataverse, SharePoint Embedded, Microsoft 365, Azure AI — the underlying services Spaarke runs on. SLA, uptime, security patches, and capacity scale are Microsoft's, covered by the customer's M365 and Azure agreements.
• 99.9% Power Platform SLA. Microsoft support is reachable through the customer's existing channels.

The customer IT team's responsibility:

• Operate the M365 tenant the platform runs in — identity, governance, DLP, retention, audit — same as the rest of the tenant.
• Apply Spaarke managed-solution updates on the team's own schedule. Test environment first if the team's ALM process calls for it.
• First-line user support for legal-ops users; Spaarke handles second-line and technical escalation.
• Coordinate with Spaarke on tenant-level configuration changes that affect the platform (DLP scope changes, Conditional Access updates).

What this means in practice. The IT team is not running a vendor's hosted infrastructure. There is no parallel ops surface to monitor, no separate incident channel for platform issues, no vendor-cloud capacity to plan for. The platform behaves like another Power Platform application in the tenant — administered through the Power Platform admin center, monitored through the M365 service-health portal. The Spaarke support team handles application-layer issues; Microsoft handles the underlying infrastructure; the customer's team handles the tenant.

Direct support channel. No ticket queue intermediary. The customer's Spaarke administrator has direct access to Spaarke's technical team for application-layer issues. Critical platform issues (Spaarke unavailable) route to a same-day response; standard issues are handled within a business day.

Update cadence. Spaarke releases follow a regular cadence — major releases roughly twice a year, point releases for fixes and security patches as needed. Each release ships with release notes, a changelog, and (where applicable) configuration migration guidance. Updates are managed-solution imports, applied on the customer's schedule.

---

Common IT Questions

These are the questions IT teams ask most frequently during evaluation. Direct questions, direct answers.

Where is data stored? In your Microsoft 365 tenant, within Dataverse. Data residency follows your tenant's geographic configuration. If your tenant is provisioned in the EU, your Spaarke data resides in the EU. No data leaves your tenant boundary.

What is the backup and recovery model? Standard Dataverse backup. System backups run automatically every 24 hours. Manual (on-demand) backups are available at any time. Point-in-time restore is supported within the retention window. All backup operations run through the Power Platform admin center — no separate backup infrastructure required.

What is the uptime SLA? Spaarke inherits the Microsoft Power Platform SLA of 99.9% uptime. This is Microsoft's commitment, not a third-party promise layered on top.

How are admin controls managed? Through the Power Platform admin center — the same console your team uses for environment management, capacity monitoring, DLP policy enforcement, and solution lifecycle management. No separate Spaarke admin portal.

How does user provisioning work? Through Microsoft Entra ID. Assign users to the appropriate Dataverse security roles and they have access. No separate user directory. No sync to manage. Offboarding follows the same process as any other M365 application — remove the role assignment or disable the account.

How does audit logging work? Two layers. The Microsoft 365 unified audit log captures platform-level activity. Dataverse audit tables capture data-level changes — who modified which record, when, and what the previous value was. Both are accessible through your existing compliance and monitoring tools.

What is the update cadence? Spaarke delivers updates as managed solution packages through standard Dataverse solution management. Your team controls the timing of updates — solutions are not force-pushed. You review release notes, test in a non-production environment if desired, and apply the update on your schedule.

What is the support model? Spaarke provides direct support with defined response times based on severity. Critical issues (platform unavailable) receive priority response. Standard issues are handled through a dedicated support channel. Your team always has direct access to Spaarke's technical team — no ticket queue intermediary.

Does Spaarke support multi-environment strategies? Yes. Development, test, and production environment separation follows standard Power Platform ALM practices. Solutions promote through environments using the same managed solution framework your team already uses.

How does data migration work? Spaarke provides import tools and migration services for existing matter data, spend and invoice history, and document libraries. Migration is scoped during implementation planning and executed in coordination with your IT team to validate data integrity at each stage.

---

Where to Go Next

This article is the technical reference for IT teams evaluating Spaarke. For the strategic context behind the architectural decisions described here, see Why We Built on Microsoft. For the business case for Tenant Dedicated Deployment, see Tenant Dedicated Deployment: The New On-Premises. For the data sovereignty principles that this architecture enforces, see Your Legal Data Belongs to You.