Enterprise Documentation

What this means

• The left rail contains the permanent workspaces: Command Center, Onboarding, Publishing, Inbox / Cases, Listening / Analytics, and Admin / Governance.
• Each workspace has one main job, so users can find the right tool without reading internal setup notes.
• Most records belong to an organization and may also belong to a business unit, brand, team, or social account.
• When a capability is unavailable, the interface should explain whether the issue is permissions, setup, account health, or provider support.

How to operate it

1. 1Start in Command Center to see readiness, notifications, and the fastest route to the work you need.
2. 2Choose Documentation when you need product guidance and Help when you need commands or configuration support.
3. 3Use workspace filters before reviewing sensitive posts, cases, reports, or account information.
4. 4Share request IDs and visible error messages with your support team when something does not work as expected.

Accessibility checks

• Use keyboard navigation to reach the left rail, top bar controls, workspace tabs, and primary tables.
• Confirm visible focus moves in the same order as the page content.
• Use meaningful workspace names and record titles so screen reader users can identify context.
• Keep zoom at 200 percent usable without horizontal scrolling outside wide data tables.

Guardrails

• Do not treat unsupported provider actions as available just because a local record exists.
• Do not use screenshots alone when the platform has audit history or exportable evidence.
• Do not share accounts between staff members.
• Do not put client-specific procurement claims into generic product documentation.

What this means

• The workspace profile identifies the organization, administrator, operating model, channels, and support contacts.
• Team invitations are a first step because enterprise social work depends on scoped collaboration.
• Starter imports can add staff, business units, brands, teams, social accounts, response templates, listening topics, and planned content.
• Readiness checks show what is complete, what is blocked, and what can be deferred with an explanation.

How to operate it

1. 1Complete the two-step workspace setup form with organization details and operating profile.
2. 2Invite the first teammates before moving deep into channel setup.
3. 3Add at least one business unit, brand, and social account so the dashboard has real operating context.
4. 4Run initialization, review readiness, and enter the dashboard when the setup criteria are satisfied.

Accessibility checks

• Every setup field must have a visible label and clear error text.
• Progress indicators must not rely on color alone; the current step should include text and state.
• Invite and import results should be announced as plain text, not only icon changes.
• Manual invitation links should be easy to select and copy without pointer-only interaction.

Guardrails

• Do not skip team invitations for an enterprise workspace unless the readiness screen records the deferral.
• Do not import staff without valid work emails and role assignments.
• Do not connect accounts to the wrong brand or business unit.
• Do not enter the dashboard with missing operating structure unless the blocker is intentionally deferred.

What this means

• Each user has a membership in the organization and one or more scoped role assignments.
• Roles grant specific permissions such as managing users, approving posts, publishing posts, exporting reports, or managing automation.
• Sessions represent signed-in users and should be revoked or rotated when access changes or risk is detected.
• Access decisions should be visible enough for admins and support staff to explain why a control is disabled.

How to operate it

1. 1Use Admin / Governance to review users, status, roles, permissions, default scope, and account access.
2. 2Create custom roles only when built-in roles do not match a real job responsibility.
3. 3Disable users who leave the organization and preserve their history for review.
4. 4Run access reviews before procurement, audit, or major staffing changes.

Accessibility checks

• User and role tables need row headers, visible status text, and keyboard-accessible actions.
• Permission labels should be written in plain language, not only as internal keys.
• Errors for denied access should include the missing permission or setup requirement.
• Session and access review evidence should be exportable in formats reviewers can read with assistive technology.

Guardrails

• Do not give publishing permission to users who only need to draft or review content.
• Do not use broad organization-wide grants when a brand or account-scoped grant is enough.
• Do not delete access history to hide an old mistake.
• Do not rely on shared inboxes or shared admin credentials for accountability.

What this means

• The organization is the top-level workspace boundary.
• Business units represent departments, programs, divisions, or other operating groups.
• Brands represent public-facing identities, campaigns, programs, or entities that own content.
• Social accounts connect channels to brands and determine where publishing, inbox, listening, and reporting records belong.

How to operate it

1. 1Create business units before assigning users and accounts.
2. 2Create brands and map each brand to the correct business unit.
3. 3Assign teams and account owners so responsibility is clear during approvals and escalations.
4. 4Use access reviews and audit exports to confirm the model still matches the organization.

Accessibility checks

• Use clear names for business units, brands, and teams so abbreviations do not block understanding.
• Keep organization selectors labeled and keyboard reachable.
• Show selected organization, business unit, brand, and account as text in the top bar.
• Avoid relying on color alone to show active scope.

Guardrails

• Do not move records across organization boundaries.
• Do not leave social accounts unassigned after launch.
• Do not hide governance issues with global filters.
• Do not let a brand owner manage unrelated brands without an explicit grant.

What this means

• Readiness cards show whether the workspace is ready for real operations.
• Notifications call attention to assigned work, setup issues, and operations that need review.
• Global filters let users narrow the dashboard by organization, business unit, brand, and account.
• Quick actions should only appear when the user has the required permission and setup context.

How to operate it

1. 1Check notifications and readiness before starting daily work.
2. 2Set filters to the business unit, brand, or account you are responsible for.
3. 3Use quick actions to create posts, review cases, inspect providers, or open onboarding tasks.
4. 4Open Documentation from the rail when you need guidance for a workspace.

Accessibility checks

• Search, filters, create actions, notifications, Help, and Documentation need consistent heights and focus states.
• Notification counts should be text-readable and not conveyed only by badges.
• Drawer controls should trap focus while open and return focus when closed.
• Keyboard users should be able to reach every top bar control in a predictable order.

Guardrails

• Do not use Command Center as a substitute for detailed workspace review.
• Do not assume hidden actions are broken; they may be blocked by permission or setup.
• Do not ignore readiness warnings before entering live operations.
• Do not use filters to conceal unresolved risk.

What this means

• Posts move through visible states such as draft, submitted, approved, scheduled, published, failed, duplicated, and archived.
• Targets connect a post to one or more social accounts and provider capabilities.
• Validation checks content, assets, account readiness, accessibility metadata, and provider support before publishing.
• Timeline and version history help reviewers understand how content changed.

How to operate it

1. 1Create a draft with the right campaign, brand, account target, and assets.
2. 2Validate the post before approval or scheduling.
3. 3Submit for approval when your role requires review.
4. 4Review publish status and retry failed jobs through the documented retry workflow.

Accessibility checks

• Post composer fields must have labels, helper text, and clear validation messages.
• Validation results should list each issue in text, not only icons.
• Approval and publish controls should remain keyboard accessible.
• Scheduled dates and times should include timezone context.

Guardrails

• Do not publish content without required alt text or caption metadata.
• Do not bypass approval because a provider target is available.
• Do not assume every provider supports the same media, link, or caption rules.
• Do not retry failed publishing outside the tracked workflow.

What this means

• Assets can include images, video, captions, text snippets, templates, PDFs, and brand files.
• Metadata describes ownership, brand, folder, collection, tags, rights, approval status, and usage.
• Alt text and caption status are part of asset readiness.
• Restricted assets require explicit visibility and should not appear broadly.

How to operate it

1. 1Upload assets, confirm the upload, and complete metadata before use.
2. 2Add tags, folders, and collections so teams can find approved material.
3. 3Approve or reject assets before attaching them to posts.
4. 4Review usage history before archiving, replacing, or reusing important assets.

Accessibility checks

• Images need meaningful alt text before publication.
• Videos need captions or a documented caption status before use.
• Asset status, rights, and restrictions should be visible as text.
• File inputs and download controls should work without pointer-only gestures.

Guardrails

• Do not publish media with missing accessibility metadata when it is required.
• Do not use assets after rights expire.
• Do not expose restricted assets to broad roles.
• Do not archive an asset before checking where it is used.

What this means

• Campaigns connect organic planning, publishing work, audiences, assigned accounts, and reporting goals.
• Paid social surfaces show accounts, campaigns, budgets, performance snapshots, alerts, and planning rules.
• Paid social planning can be useful even when live provider buying is not enabled.
• Budget and optimization decisions need clear review before provider-side changes are made.

How to operate it

1. 1Create the campaign brief, audience, goals, owner, assigned accounts, and planned content.
2. 2Link planned posts to campaign calendar items.
3. 3Review paid performance snapshots and budget alerts before changing plans.
4. 4Use local planning records for governance until live buying has been approved.

Accessibility checks

• Budget and performance numbers should include labels, units, and dates.
• Charts or trend summaries need nearby text equivalents.
• Campaign status should be readable without relying on color alone.
• Budget review controls should be reachable and understandable by keyboard.

Guardrails

• Do not claim provider-side ad buying is connected until it is approved and visible.
• Do not apply budget changes without documented review.
• Do not mix organic publishing approval with paid media approval unless your policy allows it.
• Do not treat stale performance snapshots as current results.

What this means

• Inbox interactions represent incoming community or social engagement.
• Cases are used when an item needs ownership, escalation, investigation, or follow-up.
• Assignments, notes, watchers, attachments, and timeline events preserve context.
• Saved replies and response templates help teams respond consistently.

How to operate it

1. 1Filter inbox items by account, status, owner, severity, source, or due date.
2. 2Assign interactions or create cases when a response needs accountability.
3. 3Use internal notes for context and public replies only for appropriate content.
4. 4Resolve or archive cases with a clear reason and retained history.

Accessibility checks

• Message bodies, contacts, handles, and case titles should be text-readable in tables.
• Assignment and escalation controls should identify the selected case or interaction.
• Saved reply insertion should not move focus unexpectedly.
• Status changes should be announced with readable confirmation text.

Guardrails

• Do not put private data into public replies.
• Do not close cases without the required resolution context.
• Do not assume every provider supports every engagement action.
• Do not move sensitive escalations into untracked private channels.

What this means

• Listening topics define keywords, hashtags, sources, thresholds, owners, and alert behavior.
• Mentions can become cases or evidence when they require action.
• Reports summarize campaign, account, engagement, trend, and governance information.
• Exports and share links preserve review history and access controls.

How to operate it

1. 1Create listening topics for campaigns, policy issues, reputation risks, or support themes.
2. 2Review mentions and trends before creating cases or alerts.
3. 3Build saved reports for repeated leadership, campaign, compliance, or procurement reviews.
4. 4Export reports through the platform workflow so access and audit history remain intact.

Accessibility checks

• Report tables should include clear column headers and row labels.
• Trend summaries need text equivalents for charts or visual indicators.
• Export formats should preserve headings, reading order, and meaningful labels.
• Alert severity should be communicated with text, not only color.

Guardrails

• Do not treat provider metrics as complete when account health is limited or stale.
• Do not share report links outside approved access controls.
• Do not use automation as the only review step for high-risk topics.
• Do not remove context needed to understand a trend or mention.

What this means

• Automation rules can tag, assign, create cases, route approvals, schedule reports, create exports, and record evidence.
• Rules should be previewed before they affect live work.
• AI assistance is for drafts, summaries, alt text support, and review preparation when enabled by policy.
• Human approval remains required for external communications when policy requires it.

How to operate it

1. 1Start automation with low-risk tagging, assignment, and alert rules.
2. 2Preview rules against real records before enabling them.
3. 3Review execution history after each automated action.
4. 4Use AI assistance to prepare text, then review and approve before publishing or responding.

Accessibility checks

• AI-assisted text must be reviewed for plain language and accessibility before use.
• Generated alt text must be checked by a human before publication.
• Automation results should be readable as text in execution history.
• Users need a visible way to identify when content was AI-assisted.

Guardrails

• Do not let automation hide work from owners.
• Do not let AI bypass response templates, approvals, or retention policy.
• Do not automate external provider actions without explicit approval controls.
• Do not use AI outputs as final accessibility evidence without human review.

What this means

• Providers have definitions, supported actions, required scopes, account connections, health checks, metrics, and operation history.
• A connection can be live, sandbox, manual, limited, disconnected, or unsupported depending on setup and provider capability.
• Credential details should be represented as safe status, never as visible secrets.
• Provider limitations should remain visible to operators so they know what can and cannot happen.

How to operate it

1. 1Connect channels from onboarding or Admin / Governance.
2. 2Review account health before publishing, responding, or reporting.
3. 3Reconnect accounts when permissions expire or a provider reports degraded health.
4. 4Review provider operations after publish, sync, refresh, reconnect, or revoke actions.

Accessibility checks

• Connection mode, health, and credential status should be readable text.
• OAuth or reconnect buttons should describe which provider they affect.
• Provider tables need headers for connection, provider, mode, status, health, credential, and last sync.
• Failure messages should explain the next action without exposing secrets.

Guardrails

• Do not expose raw access tokens, refresh tokens, passwords, or client secrets.
• Do not assume every provider supports every action.
• Do not publish or respond through an unhealthy connection.
• Do not ignore provider rate limits, expired permissions, or unsupported-action warnings.

What this means

• Audit history records important changes to access, content, cases, reports, provider operations, and compliance settings.
• Retention policies and legal holds help explain how records should be kept.
• Access reviews provide evidence that users and roles still match job responsibilities.
• Security and privacy evidence should be exported from governed workflows, not assembled from informal notes.

How to operate it

1. 1Review compliance controls in Admin / Governance before a procurement or security review.
2. 2Run access reviews and retain the results.
3. 3Review retention policy status before deleting, archiving, or exporting records.
4. 4Use incident and audit history when documenting operational security events.

Accessibility checks

• Audit and access review exports should preserve headings, tables, and readable timestamps.
• Compliance status must include text labels in addition to icons or colors.
• Legal hold and retention controls need clear warnings before changes are saved.
• Evidence package links should have descriptive names.

Guardrails

• Do not delete evidence needed for audit, legal hold, accessibility, or procurement review.
• Do not store secrets in documentation, screenshots, or support messages.
• Do not weaken access controls to make a workflow faster.
• Do not represent platform evidence as a replacement for organization policy.

What this means

• Readiness summarizes whether the workspace has enough structure, staff access, channels, and health evidence for real work.
• Operational history shows completed, skipped, failed, retried, or cancelled background work in user-readable terms.
• Incidents capture operational problems and resolution history.
• Release readiness evidence helps admins decide whether a change is ready for production use.

How to operate it

1. 1Review readiness after onboarding and before inviting larger teams.
2. 2Check operations history when publishing, reports, provider sync, or automation does not behave as expected.
3. 3Record incidents when a platform problem affects users or external communications.
4. 4Use readiness evidence during procurement, security, and launch reviews.

Accessibility checks

• Health and readiness statuses should include text and time context.
• Incident timelines should be readable in chronological order.
• Retry, verify, and refresh controls should have descriptive labels.
• Operational evidence should remain usable at high zoom and with keyboard navigation.

Guardrails

• Do not treat a successful login as proof that every workspace capability is ready.
• Do not ignore failed or skipped operations that affect public communications.
• Do not communicate incident status outside the platform without preserving internal evidence.
• Do not rely on undocumented manual fixes for recurring operational issues.

What this means

• Requirements can be marked supported, partially supported, planned, not supported, or needs review.
• Evidence items should link to actual product behavior, exports, controls, screenshots, accessibility artifacts, security artifacts, or review notes.
• Gap reports help teams avoid overstating current capability.
• Procurement packages should be generic and should not imply a specific agency or customer inside the product.

How to operate it

1. 1Map each important requirement to the current platform capability.
2. 2Attach evidence to supported and partially supported requirements.
3. 3Generate a gap report before responding to procurement questions.
4. 4Review accessibility, security, reporting, support, and pricing sections before submission.

Accessibility checks

• Evidence packages should include headings, meaningful link text, readable tables, and exportable text.
• Accessibility evidence should name the workflow, component, result, date, and reviewer.
• Screenshots should be paired with text summaries.
• Procurement exports should support assistive technology review.

Guardrails

• Do not overstate planned or partial features.
• Do not use unsupported provider behavior as evidence of live capability.
• Do not skip accessibility evidence for public-sector procurement.
• Do not include customer-specific private details in reusable product documentation.

What this means

• Accessibility checks should cover keyboard access, focus order, screen reader labels, color contrast, responsive layout, captions, alt text, and readable exports.
• Content accessibility includes alt text, captions, plain-language response templates, accessible PDFs, and review evidence.
• Mobile readiness means key workflows remain usable on smaller screens without hiding required context.
• Training evidence helps prove staff know how to use the accessible workflow.

How to operate it

1. 1Review accessibility checks before rollout and after meaningful UI changes.
2. 2Confirm assets have alt text and videos have captions before publication.
3. 3Use onboarding and training records to show staff were taught the required workflow.
4. 4Export accessibility evidence for procurement, VPAT support, or internal accessibility review.

Accessibility checks

• Test core workflows with keyboard only: sign in, invite staff, create post, approve post, respond to case, export report, and review audit history.
• Check screen reader names for buttons, inputs, navigation, filters, status badges, and table actions.
• Confirm color contrast meets WCAG 2.2 AA for text, controls, focus states, and status indicators.
• Verify forms identify errors with text and focus guidance.

Guardrails

• Do not treat visual polish as accessibility compliance.
• Do not use color as the only way to communicate state.
• Do not publish public content without required accessibility metadata.
• Do not claim Section 508 or WCAG conformance without evidence from the relevant workflow.

What this means

• A launch-ready workspace has an owner, staff access, operating structure, social accounts, provider status, onboarding completion, and evidence review.
• Email delivery should work before teams rely on invitations or sign-in codes.
• Provider setup should show which channels are connected, limited, manual, or unsupported.
• Admins should understand which live actions are available and which remain blocked by policy or provider support.

How to operate it

1. 1Create a test staff invitation and confirm the recipient can accept it.
2. 2Sign out and sign back in with a one-time code before inviting broad teams.
3. 3Confirm the first business unit, brand, team, and social account appear in dashboard filters.
4. 4Run a small readiness review: create a draft, attach an asset, validate it, assign a case, generate a report, and review audit history.

Accessibility checks

• Include accessibility checks in the launch checklist, not only security checks.
• Verify sign-in, onboarding, dashboard navigation, and report export at 200 percent zoom.
• Confirm staff can complete setup tasks without mouse-only interactions.
• Document any accessibility exceptions before launch.

Guardrails

• Do not launch with only the first admin tested.
• Do not invite broad teams before sign-in, invitations, and role scopes are verified.
• Do not enable external communications until approval and provider status are understood.
• Do not treat unresolved readiness blockers as cosmetic issues.

What this means

• Access evidence includes users, roles, scoped grants, session history, denied actions, and access reviews.
• Operations evidence includes readiness, incidents, provider status, report delivery, retries, and release review.
• Supplier evidence includes connected providers, account health, supported actions, limitations, and credential status.
• Compliance evidence includes audit exports, retention status, procurement evidence, accessibility records, and review history.

How to operate it

1. 1Map OASIS evidence surfaces to your organization's control owners and review cadence.
2. 2Run access reviews on a defined schedule.
3. 3Review provider and supplier evidence before adding new channels.
4. 4Export audit, accessibility, and procurement evidence for review periods.

Accessibility checks

• Keep control evidence in accessible formats with headings, labels, and readable tables.
• Ensure audit exports can be reviewed with assistive technology.
• Include accessibility ownership in the control map.
• Review accessibility exceptions as part of risk and management review.

Guardrails

• Do not represent readiness evidence as certification.
• Do not skip organization-specific policies, risk assessment, vendor review, or management review.
• Do not rely on screenshots alone when exportable evidence exists.
• Do not leave unsupported provider behavior undocumented.