Content Management liefert eine vollständige Plattform für Webinhalte und Portale. Administratoren erstellen und betreiben beliebig viele Portalseiten, jede nach ihrer Zielgruppe als Internet-, Extranet- oder Intranet-Property klassifiziert und jede mit eigener Domain, eigenem Branding und eigener Zugriffskonfiguration. Innerhalb einer Seite bauen sie mit einem blockbasierten Editor eine Hierarchie von Seiten auf, ordnen diese Seiten in hierarchische Navigationsmenüs ein und pflegen eine seitenspezifische Medienbibliothek aus Bildern und Dokumenten, wobei Alternativtext und Bildunterschriften zu jedem Asset hinterlegt werden.

Seiten werden aus komponierbaren Content-Blöcken zusammengesetzt statt aus handgeschriebenem Markup: Überschriften mit expliziten Ebenen, formatierte Absätze, aus der Bibliothek eingebundene Bilder, Callouts in den Varianten Information, Warnung, Erfolg und Fehler, geordnete und ungeordnete Listen, Trennlinien sowie bereinigtes Raw-HTML für die Fälle, die es benötigen. Ein Theme-System gibt jedem Portal seine eigene Farbpalette, Typografie, Logos, Favicon sowie eigene Header, Footer und Stylesheets, die zur Renderzeit als Design-Tokens eingespielt werden. Multi-Site-Management bedeutet, dass ein Team dutzende Properties, öffentliche wie private, aus einer Konsole betreibt, mit einem einheitlichen Publishing-Modell über alle hinweg.

Das Modell beruht auf einer kleinen Zahl von Konzepten, die sich direkt darauf abbilden lassen, wie ein Kommunikationsteam ohnehin denkt. Ein Portal ist eine vollständige Seite mit einer Zielgruppe, einer Webadresse und einem Publishing-Status, der es zwischen Entwurf, veröffentlicht, Wartung und deaktiviert bewegt. Nur ein veröffentlichtes Portal wird an Besucher ausgeliefert, was Redakteuren einen sicheren Ort gibt, um Arbeiten vorzubereiten, bevor sie live gehen, und einen sauberen Weg, eine Property offline zu nehmen, ohne sie zu löschen.

Jedes Portal enthält Seiten, und Seiten verschachteln sich ineinander und bilden so die natürliche Eltern-Kind-Struktur einer Website. Eine Seite trägt ihren Inhalt als geordnete Folge von Blöcken, ein Template, das sie rahmt, und eine Zugriffsebene, die entscheidet, wer sie sehen darf: offen für jeden, beschränkt auf authentifizierte Besucher oder auf interne Benutzer nach Rolle begrenzt. Die Navigation wird getrennt von den Seiten selbst modelliert, als eigenes geordnetes und verschachtelbares Set von Links, die auf eine Seite oder auf eine beliebige Adresse verweisen können, sodass das Menü, das ein Besucher sieht, bewusst kuratiert ist und nicht ein mechanisches Abbild des Seitenbaums. Medien-Assets gehören zu ihrem Portal, wodurch die Bibliothek jeder Seite in sich geschlossen bleibt. Das Ergebnis ist eine klare Trennung zwischen dem, was eine Seite aussagt, wo sie liegt, wie sie erreicht wird und wer sie erreichen darf.

Ein typischer Einsatz beginnt damit, dass ein Autor ein Portal anlegt, seinen Typ wählt und seine Domain beansprucht und dann ein Theme festlegt, sodass die Property von der ersten Seite an das korrekte Branding trägt. Redakteure fügen im Blockeditor Seiten hinzu, komponieren Inhalte visuell, binden Medien aus der Bibliothek ein, füllen die SEO-Felder aus, die bestimmen, wie jede Seite in Suchmaschinen und Social-Media-Vorschauen erscheint, und legen die Zugriffsebene fest, die gelten soll, sobald die Seite live ist. Die Navigation wird in einem eigenen Editor arrangiert, in dem Links sortiert, zu Menüs gruppiert und mit eigenen Sichtbarkeitsregeln versehen werden.

Inhalte durchlaufen einen Publishing-Workflow, statt sofort zu erscheinen. Seiten werden im unveröffentlichten Zustand entworfen und geprüft, dann bewusst veröffentlicht, und ein Portal als Ganzes kann im Entwurf gehalten oder in den Wartungszustand versetzt werden, ohne dass Arbeit verloren geht. Weil Seiten zentral gesteuert werden, kann ein einzelner Bearbeiter eine koordinierte Änderung, eine neue Kampagnenseite, ein überarbeitetes Menü, ein neu gebrandetes Theme, in einem Zug über mehrere Portale ausspielen. Der Zugriff wird durchgängig durchgesetzt: Eine Seite, die für authentifizierten oder rollenbasierten Zugriff markiert ist, verlangt, dass sich der Besucher anmeldet und, wo konfiguriert, aus einem freigegebenen Netzwerk stammt, bevor der Inhalt gerendert wird.

Im funktionalen Detail rechtfertigt das Modul seinen Platz. Die Zugriffssteuerung ist mehrschichtig und präzise. Öffentliche Seiten werden offen ausgeliefert, authentifizierte Seiten erfordern Single Sign-on über Home Realm Discovery, die die E-Mail-Domain eines Besuchers auf den korrekten Identity Provider abbildet, und rollenbasierte Seiten sind internen Benutzern vorbehalten, wobei Intranet-Properties zusätzlich durch die Netzwerkadresse eingeschränkt werden, sodass Mitarbeiterinhalte nur von vertrauenswürdigen Standorten aus erreichbar sind. So kann eine einzige Plattform eine Marketingseite, ein Partner-Extranet und ein vertrauliches Mitarbeiter-Intranet sicher hosten, ohne jedes Risiko, dass die falsche Zielgruppe an den falschen Inhalt gelangt.

Das Rendering ist auf Sicherheit und Qualität ausgelegt. Raw-HTML-Blöcke werden bereinigt, bevor sie einen Browser erreichen, sodass Redakteure flexibel bleiben, ohne eine Angriffsfläche für Injection zu öffnen. Strukturierte Blöcke tragen die Semantik, von der Barrierefreiheit abhängt, einschließlich expliziter Überschriftenebenen und verpflichtender Alternativtexte an Bildern, und seitenspezifische SEO-Metadaten geben jeder Seite korrekte Titel, Beschreibungen und Vorschauen. Themes werden zu Design-Tokens aufgelöst, die am Dokument-Root angewendet werden, was das Branding über jede Seite einer Website hinweg konsistent und performant hält. Domainbasiertes Routing löst jede eingehende Anfrage anhand des Hostnamens ihrem Portal zu, wendet das Theme und die Navigation dieses Portals an und liefert nur Inhalte aus, deren Seite und Portal beide veröffentlicht sind, sodass unfertiges oder zurückgezogenes Material niemals nach außen gelangt.

Content Management ist bewusst kein eigenständiger Website-Baukasten. Es stützt sich für seine administrative Hülle, Autorisierung und Auditierung auf die zentralen Systemdienste der Plattform, und es baut auf Connector Management für die zwei Dinge, die ein Portal nicht selbst erfinden kann: die Identity Provider, die Extranet- und Intranet-Besucher authentifizieren, und die Integrationen, die es externen Content-Systemen erlauben, Portalinhalte zu speisen oder zu spiegeln. Jede Zugriffsentscheidung, die ein Portal trifft, nutzt das Single Sign-on und das Verzeichnis der Suite erneut, sodass ein Partner, der sich in ein Extranet einloggt, dieselbe verwaltete Identität ist, die der Rest von Nashua 360 bereits kennt.

Dieses gemeinsame Fundament macht die Portale wirklich nützlich statt dekorativ. Ein Kundenportal stellt Informationen und Self-Service bereit, die aus den dahinterliegenden operativen Modulen stammen, seien es Konto- und Beziehungsdaten aus dem CRM-Modul, Fälle und Wissen aus dem Support oder Kontoauszüge und Dokumente aus Finanzwesen und Dokumentenmanagement. Weil dasselbe Berechtigungsmodell das Dashboard und die Portale steuert, kann eine Seite gefahrlos Daten präsentieren, die einem angemeldeten Kunden oder Mitarbeiter gehören. Content Management fungiert damit als Präsentations- und Engagement-Schicht für die gesamte Suite und gibt jedem anderen Modul einen gebrandeten, zugriffskontrollierten Weg, die Menschen außerhalb der Anwendung zu erreichen.

AI Workers agieren in Content Management als vollwertige Beteiligte, nicht als aufgesetzter Assistent. Ein Bearbeiter kann in natürlicher Sprache fragen, welche Seiten über alle Portale hinweg unveröffentlicht sind, wo ein eingestelltes Produkt noch referenziert wird oder bei welchen Bildern der Alternativtext fehlt, und erhält eine direkte Antwort aus den Live-Daten des Moduls. Worker führen auf Anforderung Aktionen innerhalb ihrer gewährten Berechtigungen aus: das Entwerfen und Befüllen einer Seite aus einem Briefing, das Erzeugen von SEO-Titeln und -Beschreibungen, das Umstrukturieren eines Navigationsmenüs oder das Ausrollen einer Theme-Änderung über eine Reihe von Seiten.

Sie beobachten außerdem kontinuierlich. Ein Worker markiert Anomalien und Ausnahmen, ein Portal, das zu lange in Wartung steht, eine veröffentlichte Seite, deren Zugriffsebene inkonsistent zu ihrem Inhalt wirkt, defekte interne Links oder unbereinigtes Markup, und meldet sie, bevor ein Besucher sie je zu sehen bekommt. Bei der Aufnahme extrahiert und strukturiert er Inhalte und verwandelt ein bereitgestelltes Dokument oder eine Seite aus einem angebundenen externen System in saubere Blöcke mit Überschriften, Listen und Medien mit Bildunterschriften. Im Publishing-Workflow dient ein Worker als Prüf- und Freigabeknoten, der einen Entwurf gegen Marken-, Barrierefreiheits- und Zugriffsrichtlinien prüft und ihn entweder freigibt, Änderungen anfordert oder an einen menschlichen Redakteur eskaliert. Durchgehend bieten Worker Entscheidungsunterstützung, empfehlen, wo neuer Inhalt hingehört, welche Zielgruppe eine Seite ansprechen sollte und wie sich die Struktur einer Website vereinfachen lässt, sodass das Team schneller und mit weniger Fehlern veröffentlicht.