Content Management delivers a complete web content and portal platform. Administrators create and run any number of portal sites, each classified by its audience as an internet, extranet or intranet property, and each carrying its own domain, branding and access posture. Inside a site they build a hierarchy of pages using a block-based editor, arrange those pages into hierarchical navigation menus, and curate a per-site media library of images and documents with alternative text and captions held alongside every asset.

Pages are assembled from composable content blocks rather than hand-cut markup: headings with explicit levels, rich paragraphs, images drawn from the library, callouts in informational, warning, success and error variants, ordered and unordered lists, dividers and sanitised raw HTML for the cases that need it. A theme system gives each portal its own palette, typography, logos, favicon and custom header, footer and stylesheet, injected as design tokens at render time. Multi-site management means one team operates dozens of properties, public and private, from one console, with a consistent publishing model across all of them.

The model rests on a small number of concepts that map directly to how a communications team already thinks. A portal is a complete site with an audience, a web address and a publishing state that moves it between draft, published, maintenance and disabled. Only a published portal is served to visitors, which gives editors a safe place to prepare work before it goes live and a clean way to take a property offline without deleting it.

Every portal contains pages, and pages nest inside one another to form the natural parent and child structure of a site. A page carries its content as an ordered sequence of blocks, a template that frames it, and an access level that decides who may see it: open to anyone, restricted to authenticated visitors, or limited to internal users by role. Navigation is modelled separately from the pages themselves, as its own ordered and nestable set of links that may point at a page or at any address, so the menu a visitor sees is curated deliberately rather than being a mechanical echo of the page tree. Media assets belong to their portal, keeping each site's library self-contained. The result is a clean separation between what a page says, where it lives, how it is reached and who is allowed to reach it.

A typical engagement begins with an author creating a portal, choosing its type and claiming its domain, then setting a theme so the property carries correct branding from the first page. Editors add pages in the block editor, composing content visually, attaching media from the library, filling in the SEO fields that govern how each page presents to search engines and social previews, and setting the access level that will apply once the page is live. Navigation is arranged in a dedicated editor where links are ordered, grouped into menus and given their own visibility rules.

Content moves through a publishing workflow rather than appearing instantly. Pages are drafted and reviewed while unpublished, then published deliberately, and a portal as a whole can be held in draft or dropped into maintenance without losing any work. Because sites are governed centrally, a single operator can push a coordinated change, a new campaign page, a revised menu, a rebranded theme, across several portals in one sitting. Access is enforced end to end: a page marked for authenticated or role-based access requires the visitor to sign in and, where configured, to fall inside an approved network before the content is rendered.

The functional detail is where the module earns its place. Access control is layered and precise. Public pages are served openly, authenticated pages require single sign-on through home realm discovery that maps a visitor's email domain to the correct identity provider, and role-based pages are reserved for internal users, with intranet properties additionally constrained by network address so that employee content is only reachable from trusted locations. This lets one platform safely host a marketing site, a partner extranet and a confidential staff intranet without any risk of the wrong audience reaching the wrong content.

Rendering is engineered for safety and quality. Raw HTML blocks are sanitised before they reach a browser, so editors retain flexibility without opening an injection surface. Structured blocks carry the semantics that accessibility depends on, including explicit heading levels and mandatory alternative text on imagery, and per-page SEO metadata gives every page correct titles, descriptions and previews. Themes resolve to design tokens applied at the document root, which keeps branding consistent and performant across every page of a site. Domain-based routing resolves each incoming request to its portal by host name, applies that portal's theme and navigation, and serves only content whose page and portal are both published, so unfinished or withdrawn material is never exposed.

Content Management is deliberately not a standalone website builder. It depends on the platform's core system services for its administrative shell, authorisation and audit, and it leans on Connector Management for the two things a portal cannot invent for itself: the identity providers that authenticate extranet and intranet visitors, and the integrations that let external content systems feed or mirror portal content. Every access decision a portal makes reuses the suite's single sign-on and directory, so a partner who logs into an extranet is the same governed identity the rest of Nashua 360 already knows.

This shared foundation is what makes the portals genuinely useful rather than decorative. A customer portal surfaces information and self-service drawn from the operational modules behind it, whether that is account and relationship data from the CRM module, cases and knowledge from support, or statements and documents from finance and document management. Because the same permission model governs the dashboard and the portals, a page can safely present data that belongs to a signed-in customer or employee. Content Management therefore acts as the presentation and engagement layer for the whole suite, giving every other module a branded, access-controlled way to reach the people outside the application.

AI Workers operate in Content Management as first-class participants, not as a bolt-on assistant. An operator can ask, in plain language, which pages across every portal are unpublished, where a retired product is still referenced, or which images are missing alternative text, and receive a direct answer drawn from live module data. Workers execute actions on request within their granted permissions: drafting and populating a page from a brief, generating SEO titles and descriptions, restructuring a navigation menu, or rolling a theme change across a set of sites.

They also watch continuously. A Worker flags anomalies and exceptions, a portal left in maintenance too long, a published page whose access level looks inconsistent with its content, broken internal links, or unsanitised markup, and raises them before a visitor ever sees them. On ingestion they extract and structure content, turning a supplied document or a page from a connected external system into clean blocks with headings, lists and captioned media. In the publishing workflow a Worker serves as a review and approval node, checking a draft against brand, accessibility and access-policy rules and either approving it, requesting changes, or escalating to a human editor. Throughout, Workers offer decision support, recommending where new content belongs, which audience a page should target, and how a site's structure can be simplified, so the team publishes faster and with fewer errors.