Reference
About these docs
How this documentation is organised, the conventions every page follows, how screenshots and evidence are kept, and how to propose a change.
- Everyone
Last reviewed
This documentation explains Flexday AI for everyone who works with it: functional users who own a process and decide whether it fits, builders making Solutions, and architects, security teams and buying committees reviewing how it works. Every page starts with the plain-language "what and why" and then goes deeper.
How it is organised
| Section | What it answers |
|---|---|
| Getting started | What Flexday AI is and how a Solution comes together |
| Evaluating Flexday AI | For a buying committee: security, privacy, responsible AI, deployment and residency, reliability, compliance support, fit with your stack, portability and a proof-of-concept plan |
| Architecture | How the platform is built, deployed and extended |
| Governance | How data, access, secrets and AI are kept safe |
| Capabilities | What you can do, written as outcomes |
| Components | What each part is, how it works, and its limits |
| Use cases | Worked examples of components working together |
| Reference | The glossary, limits and quotas, and this page |
Reading paths
| If you are | Start with |
|---|---|
| A functional user | Welcome, Platform at a glance, Governance overview, Deployment models, the Service Desk Copilot |
| Evaluating Flexday AI for your organisation | Evaluating Flexday AI, then the page for your role in its reading paths |
| A builder | How a Solution comes together, Build by conversation, then the component pages you need |
| An architect | Architecture overview, Runtime services, Request paths, Data architecture |
| A security reviewer | Governance overview, Data isolation, Secrets and encryption, AI safety |
Conventions
- Words. Component names are capitalised as the product shows them: Solution, LaunchPad, Fact Base, Doc Base, File Store, Flow, Agent, Bot, Flex Gateway, Identity, Connection, Variable, Template, Integration, the Builder. The glossary defines the main terms used across these docs.
- Addresses.
<domain>stands for the base domain a deployment is served from, and<workspace>for a workspace's short name. - Examples. Companies, people and addresses in examples and screenshots are fictional. Example
addresses use reserved names such as
.exampleorexample.com. - Limits. Numbers on these pages are default limits; your deployment or your plan may set some of them differently.
- Diagrams. Colours carry meaning: violet for Solution resources, indigo for platform surfaces, cyan for platform services and controls, amber for data stores, slate for people and outside systems, and green, amber and red for states.
How pages are written
Every page is a Markdown file with front matter:
| Key | Meaning |
|---|---|
title | The page title and its navigation label |
description | One sentence for search results and link previews |
section | The section the page belongs to |
order | Its position within the section |
audience | everyone, leadership (shown as Functional users) and or technical |
tags | Two to six lowercase tags |
lastReviewed | The date the page was last checked against the product |
Navigation is described by index.json at the root of the documentation folder. Diagrams are SVG files
generated by the scripts in the _tools folder, so they can be changed and regenerated consistently.
How screenshots are made
Screenshots are real captures of Flexday AI, never mock-ups. A script opens each screen of a demo deployment running the same code, seeded with the fictional company Harbourline and its made-up people, and captures it at a fixed size in the light theme. The only edits allowed are a crop, a resize and a grey box over anything that must not be shown, and the script may hide passing notifications that are not part of the screen; nothing is retyped or drawn on. Each screenshot is listed in a register beside the scripts, with the page it belongs to, why it earns its place, what it shows and the date it was captured, so a screen that has changed can be captured again the same way. Screens of other companies' products, such as Microsoft Teams or ServiceNow, stay as diagrams.
How evidence is kept
Every statement on the Evaluating Flexday AI pages is recorded in an evidence register with the source code, infrastructure definitions or feature documents that back it, and an automated check confirms that each cited file exists. Facts about Flexday as a company, such as certifications, service levels and contract terms, are never stated here: the pages list them as documents to request instead.
Proposing a change
Anyone signed in with write access to the documentation repository can edit a page on the documentation site. Each edit becomes a pull request against the development branch, is reviewed, and goes live when the merged change is next deployed. If something on a page does not match what you see in the product, the product is right and the page is the bug: please propose a fix or tell your Flexday contact.