brillienta
Book a demo ↗
HOME / PRODUCTS / INTRANET BUILDER
◫ BRILLIENTA INTRANET BUILDER · VERSION 2.4
The company intranet that lives in your Microsoft 365: a corporate home site, department and HR sites, knowledge sites and a restricted administration site — designed in Setup Center from approved templates, and installed by a PowerShell provisioning engine that is idempotent, resumable and verified.
WHAT YOUR PEOPLE SEE
Every screen below is release 2.4 of the real product with a fictional sample organisation. Web parts run with each reader’s own permissions; search results are security-trimmed.
A personal greeting with campaigns, then news with image cards, announcements, events, quick links, my tasks and my requests, applications, people, ideas and documents — every web part on a card surface that follows your design.
Policies with review status, read-and-confirm acknowledgements, services, new joiners, celebrations and recognition. Each person’s confirmations stay in a restricted list.
The design studio sets the look of every web part and extension — and it is in both Setup Center and Configuration Manager, so the design is chosen before installation and carried in the installation file.
Search pages built on PnP Modern Search with SharePoint Search underneath, redesigned site templates, and new web parts for the reference designs — a news slideshow of top stories, call to action, quote and contact tables. Header and footer designs put the footer at the end of every page.
A guided setup installs Intranet Builder in about 30 minutes: double-click Setup, answer a few questions, sign in once, then design and install each site in Setup Center from your browser. The PowerShell engine still does the work — idempotent, resumable and verified.
THE DISTINCTION THAT MATTERS
The setup experience and privileged installation are deliberately separate concerns. PowerShell runs on an administrator's machine or an Azure worker — never inside the browser.
Runs in the browser, under the signed-in administrator's own permissions. It collects configuration, validates prerequisites, shows a change preview and submits a request. It never holds an installation credential.
Executes privileged installation tasks through PnP PowerShell and SharePoint administrative commands, on an administrator's computer or a queued Azure worker, inside an explicitly granted scope.
An installation service must never become a broadly privileged proxy for ordinary content access. Employees generally reach SharePoint with their own permissions, and the provisioning identity is only used for installation operations within its granted scope.
This page describes the system design. A customer should be able to install the packages, open the Setup Center, choose a template, select modules, configure branding, departments and permissions, review the changes, provision, then follow guided content population and launch checks. Initial tenant setup still requires an appropriately privileged administrator.
PRODUCT STRUCTURE
Think of the product as an Intranet Builder with five parts, each solving a different part of the problem.
Guided installation, configuration, validation and upgrades. Where the administrator does the thinking.
Reusable components for intranet pages — news, people, links, policies, events and more.
Navigation, footer, alerts, list actions and custom forms that shape the SharePoint surface.
Complete sites, pages, lists, branding and module configurations, delivered as versioned packages.
PowerShell automation for installation, repair and upgrades — the part that actually changes the tenant.
THE CUSTOMER JOURNEY
Upload the solution packages to your app catalog.
Confirm prerequisites and connect a deployment target.
Corporate, HR portal, department or knowledge hub.
Pick components; the engine resolves dependencies.
Branding, departments and permissions.
Proposed creations, updates and conflicts.
Submit the job; the engine executes the plan.
Guided content population for news, links and people.
Verify content, links, permissions and publication.
Health dashboard, upgrades and module changes.
ARCHITECTURE
Pin and test the SPFx, Node.js, React and PnP versions together for every release — the framework stack is the product's real dependency surface.
| Concern | Recommended implementation |
|---|---|
| Job storage | Azure Table Storage or a relational database |
| Package storage | Versioned Azure Blob Storage, or customer-controlled storage |
| Monitoring | Application Insights and structured job logs |
| Credentials | Managed identity where supported, otherwise certificate-based authentication |
Pinning applies to the whole release train: SPFx, Node.js, React and PnP versions are tested together, not individually.
INSTALLATION MODES
The same provisioning modules should power both modes. Start with administrator-run installation, then add the hosted worker when the customer is ready for it.
The Setup Center produces configuration; an administrator runs the PowerShell installer on their own machine. The first release, smaller customers, and restricted environments.
The Setup Center submits a job; a customer-hosted Azure worker executes provisioning. Enterprise deployments and repeated site creation.
For customers who require data to stay within their environment, deploy the worker and its operational storage into the customer's own Azure subscription. Intranet content always stays in the customer's Microsoft 365 tenant.
PACKAGE DESIGN
Keep common UI and service code in shared source packages, and bundle those dependencies into the solutions initially to reduce runtime deployment dependencies.
Setup Center, Configuration Manager and Health Dashboard.
Hero, news, links, announcements, events and FAQs.
Directory, organisation chart, recognition and celebrations.
Documents, policies, resources, service links and task summaries.
Navigation, footer, alerts, command sets and form customizers.
Optional connectors to HRMS, helpdesk, asset or task systems.
Making SPFx components available tenant-wide does not provision their supporting lists and pages on every site — Microsoft documents separate behaviour for tenant deployment and feature-based asset provisioning. Keep site provisioning in the dedicated engine. Likewise, tenant-wide availability should not automatically enable your navigation everywhere: register extensions explicitly for the intended sites, and deploy the administration package only where it is needed.
WEB PART LIBRARY
Build a focused core first, with additional modules enabled as needed. Avoid reimplementing a component merely to duplicate a native SharePoint web part — use native components in templates when they already meet the requirement.
| Web part | Features | Primary data source |
|---|---|---|
| Setup Center | Guided installation, prerequisites, template selection, progress | Configuration and provisioning API |
| Configuration Manager | Branding, module settings, navigation, data sources | Configuration lists |
| Health Dashboard | Missing lists, package versions, permissions, broken references | Validation service |
| Hero / Welcome | Campaigns, personalized greeting, calls to action | Configuration / campaign list |
| News Center | Featured stories, departments, categories, layouts | Site Pages |
| Announcements | Priority, start and end dates, audience relevance | Announcements list |
| Quick Links | Categories, icons, pinned links, layouts | Links list |
| Application Launcher | Microsoft 365 and internal application links | Application catalog list |
| Events | Calendar, agenda, categories, registration links | Events list |
| Employee Directory | Search, filters, people cards, contact actions | Graph or approved employee source |
| Organization Chart | Manager hierarchy, expandable reporting lines | Graph or HR source |
| New Joiners | Welcome cards, department, joining date | Approved employee data |
| Celebrations | Work anniversaries and optional birthdays | Consented employee data |
| Recognition | Kudos, badges, moderation | Recognition list |
| Document Center | Search, metadata filters, categories, recent documents | Libraries / SharePoint Search |
| Policy Center | Published policies, owners, review dates | Policy library |
| Policy Acknowledgements | Read-and-confirm workflow, personal completion | Restricted acknowledgement store |
| FAQ / Knowledge Base | Categories, search, useful / not useful feedback | FAQ list / pages |
| Department Overview | Contacts, services, news, related resources | Department configuration |
| Service Catalog | HR, IT and facilities services with request links | Service catalog list |
| My Requests | Personal helpdesk or service request summary | Existing application APIs |
| My Tasks | Assigned work, deadlines, source links | Selected task provider |
| Feedback / Ideas | Suggestions, moderation, status | Feedback list |
| Search Center | Results, filters, verticals, pagination | SharePoint Search |
| Page Feedback | Helpful rating and improvement suggestions | Restricted feedback store |
For Helpdesk, Asset Management and Task Management, package integration widgets separately from full business applications. An intranet summary should use the underlying application's authorisation and workflows rather than re-implementing them.
EXTENSION LIBRARY
Application Customizers should use supported placeholders. Do not build the product around replacing SharePoint's native header or manipulating its internal DOM.
| Extension | SPFx type | Purpose |
|---|---|---|
| Global navigation | Application Customizer | Configurable links and mega menu |
| Footer | Application Customizer | Corporate links, support, legal information |
| Urgent alert banner | Application Customizer | Time-limited operational announcements |
| Help launcher | Application Customizer | Contextual guidance and support links |
| Document actions | ListView Command Set | Submit for review, acknowledge, request changes |
| Content management actions | ListView Command Set | Validate metadata or request publication |
| Rich status display | Field Customizer | Interactive status or richer field rendering |
| Events form | Form Customizer | Conditional fields for event types |
| Content submission form | Form Customizer | Guided announcement or resource submission |
Use native JSON column formatting for simple visual formatting, and reserve Field Customizers for behaviour that actually requires code. Microsoft explicitly identifies the native header and internal DOM structures as unsupported dependencies — building on them makes every upgrade your problem.
SITE & DATA ARCHITECTURE
Use a corporate communication site as the main intranet, with associated department sites where separate ownership is useful. Hub association provides organisation and navigation; configure permissions separately.
| Site | Responsibility |
|---|---|
| Intranet Home | Corporate communications, entry points, search |
| HR | Employee resources and published HR content |
| IT | Support information, services, knowledge |
| Departments | Local news, resources, contacts |
| Intranet Administration | Restricted setup, templates, deployment records |
CONFIGURATION MODEL
| List / library | Important fields |
|---|---|
| IntranetSettings | Key, Scope, ValueJson, SchemaVersion |
| ModuleInstances | InstanceId, ModuleKey, SiteId, ConfigJson, Version, Status |
| NavigationItems | ParentId, Label, Url, Order, AudienceIds |
| Announcements | Title, Body, Priority, StartDate, EndDate |
| Events | Title, EventType, StartDate, EndDate, Location |
| Resources | Title, Category, Url, Owner, ReviewDate |
| Departments | DepartmentKey, Name, SiteUrl, Owner |
| ProvisioningHistory | JobId, RequestedBy, TemplateVersion, Status |
| MigrationHistory | MigrationId, SiteId, AppliedAt, ReleaseVersion |
| IntranetAssets | Logos, icons, approved images |
| Templates | Approved template packages and manifests |
Keep sensitive acknowledgements, service requests and employee information separate from broadly readable intranet lists. Targeting changes presentation; it does not restrict who can read a record.
Use native Site Pages for news and standard document libraries for documents. For list-backed components, define indexed filtering fields, server-side paging, retention and archival behaviour from the start — retrofitting them is expensive.
SETUP CENTER EXPERIENCE
An installation is complete only when the pages and modules work — not merely when the package upload succeeds.
Checks app catalog, packages, roles, API consent and target site.
Selects an existing site or requests a new one.
Corporate, HR portal, department or knowledge hub.
Selects components and resolves dependencies.
Logo, theme and typography within supported boundaries.
Creates new lists, or maps to existing sources.
Selects owners, authors, readers and approvers.
Lists proposed creations, updates and conflicts.
Progress, warnings, retry and resume.
Verifies content, links, permissions and publication.
For existing lists, validate field types and internal names before accepting a mapping. Never assume a list named "Events" follows your schema — that assumption is the most common cause of a failed installation.
TEMPLATE & MODULE CONTRACTS
Every module has a versioned manifest describing its required packages and component IDs, supporting lists, permissions, dependencies, default web part properties, compatible configuration schema versions, and validation and migration steps.
// Proposed manifest — resolved per environment at install time { "id": "events", "version": "1.0.0", "package": "intranet-core", "dependencies": ["core-config"], "dataSources": [ { "key": "events", "provisioningTemplate": "lists/events.xml", "allowExistingListMapping": true } ], "pages": [ { "template": "pages/events.json", "target": "Events.aspx" } ], "configurationSchema": "schemas/events.schema.json", "validationProfile": "events-v1" }
PROVISIONING WORKFLOW
Each step has a checkpoint, correlation ID, duration and an actionable error — so an interrupted run can be understood, not guessed at.
RELIABILITY BEHAVIOUR
A failed run may leave partially created resources. Design recovery explicitly rather than promising universal rollback — the honest promise is resumable, idempotent repair, not an atomic undo.
POWERSHELL DELIVERY
Orchestration scripts wrap actual PnP commands. The same modules power both installation modes.
| Script | Responsibility |
|---|---|
Test-Prerequisites.ps1 | Environment, identity, permissions, connectivity |
Get-DeploymentPlan.ps1 | Proposed changes and conflicts |
Install-Intranet.ps1 | Orchestrates installation |
Enable-IntranetModule.ps1 | Adds an optional module |
Update-Intranet.ps1 | Applies compatible migrations |
Test-Intranet.ps1 | Post-install health checks |
Repair-Intranet.ps1 | Repairs explicitly selected managed resources |
Export-IntranetConfiguration.ps1 | Exports settings without secrets |
Disable-IntranetModule.ps1 | Disables components while retaining content |
param( [Parameter(Mandatory)] [string]$SiteUrl, [Parameter(Mandatory)] [string]$ClientId, [Parameter(Mandatory)] [string]$TemplatePath ) $ErrorActionPreference = "Stop" # Interactive authentication needs your own Entra application / client ID Connect-PnPOnline ` -Url $SiteUrl ` -Interactive ` -ClientId $ClientId try { Invoke-PnPSiteTemplate -Path $TemplatePath } finally { Disconnect-PnPOnline }
This is a minimal template application example, not the complete installer. Interactive PnP authentication requires your own Entra application and client ID; automated execution should use an appropriate supported workload identity.
SECURITY & AUTHORIZATION
Keeping these separate is what stops an installation feature from quietly becoming a privilege-escalation path.
Default
Configuration
Execution
FOR AUTOMATED PROVISIONING
Sites.Selected requires both consent and explicit site access. It does not independently permit site creation, tenant administration, or every provisioning operation. Separate tenant bootstrap privileges from routine site updates.
SHARED WEB PART FRAMEWORK
All components follow the same internal contract, so behaviour and failure handling are consistent across every module.
Loads defaults and site or module overrides.
SharePoint, Graph and business APIs behind one interface.
Determines which actions are available.
Consistent branding with accessible contrast.
Reduces repeated requests, with explicit expiry.
Sanitised errors and performance measurements.
Stops one component breaking its own page region.
Shared labels, date handling, language support.
EVERY WEB PART PROVIDES
No component should require a provisioning backend during ordinary content rendering. Prefer shared initialisation promises and a documented initialisation lifecycle, so web parts do not intermittently load before their configuration is ready.
GUIDANCE
Each module ships with its own documentation, and errors link directly to the relevant page.
| Guidance | Content |
|---|---|
| Prerequisites | Packages, permissions, required sources |
| Setup guide | Steps to configure the module |
| Author guide | How to add and maintain content |
| Administrator guide | Permissions, ownership, settings |
| Troubleshooting | Error codes, causes, repair actions |
| Upgrade notes | Changes and migration requirements |
Events cannot load because the mapped list does not contain the required StartDate field. → Open Data Source Mapping to select a compatible list.
UPGRADES, TESTING & ROLLOUT
Package, template, configuration schema and migration versions are tracked separately, so an upgrade can be reasoned about precisely.
| Scenario | Required outcome |
|---|---|
| New tenant / site | Complete working installation |
| Existing customised site | Conflicts reported; content preserved |
| Repeat installation | No duplicates |
| Interrupted job | Safe resume |
| Missing permission | Clear failure without bypass |
| SharePoint throttling | Controlled retries |
| Package upgrade | Existing instances remain functional |
| Restricted employee | No unauthorised data exposure |
| Module disablement | Content retained |
| Keyboard / mobile use | Core journeys remain usable |
PRICING
A flat monthly price per tenant, by number of sites. Every package includes upgrades and the full setup tools.
A modern intranet for a smaller organisation
billed yearly · $1,788 / year
Every template and module for a growing intranet
billed yearly · $4,188 / year
Everything in Essentials, plus:
Intranets at scale, provisioned automatically
tailored to your sites and rollout
Everything in Professional, plus:
Prices in USD per tenant, excluding taxes. Site counts include the restricted administration site. A one-off design and rollout service is available with any package.
RESOURCES
The complete documentation, our security model and practical articles for Intranet Builder.
INTRANET BUILDER QUESTIONS
These are the questions that decide whether this is the right shape of product for you.
Discuss your tenant ↗No. The web part manages the setup experience — collecting configuration, validating prerequisites and showing a change preview. A provisioning engine performs the privileged installation, running PowerShell on an administrator's computer or an Azure worker, never inside the browser.
Administrator-run installation. It lets you prove templates, component dependencies, upgrades and repair behaviour before building a hosted provisioning platform. The same provisioning modules power both modes, so nothing is thrown away when you move to automation.
Yes. For customers who require data to stay within their environment, deploy the worker and its operational storage into their subscription. Intranet content always stays in the customer's Microsoft 365 tenant.
The change preview lists proposed creations, updates and conflicts before anything runs. The engine tracks which resources it manages, detects conflicts, and avoids overwriting customer-edited pages. Your content is preserved and reported.
Yes. Idempotency is a required behaviour: rerunning setup must not duplicate lists, pages or navigation. Interrupted runs resume from verified checkpoints.
Yes. Idempotency is a required behaviour: rerunning setup must not duplicate lists, pages or navigation. Interrupted runs resume from verified checkpoints.
Yes, with validation. Field types and internal names are checked before a mapping is accepted — a list named "Events" is not assumed to follow our schema. Existing list mapping is declared per module in its manifest.
Because Microsoft explicitly identifies the native header and internal DOM structures as unsupported dependencies. Application Customizers use supported placeholders so your product keeps working after platform upgrades.
Only what installation requires, and only for approved templates and packages. Certificates, secrets and elevated tokens never appear in SPFx bundles or lists, arbitrary uploaded scripts are never executed, and every requested target site is authorised server-side.
Versions are pinned and tested together as a release train — SPFx, Node.js, React and PnP. PnP is community-supported tooling, so the product carries its own compatibility testing and support process rather than inheriting one implicitly.
INSTALL ONCE. UPGRADE SAFELY.