# Core Concepts Source: https://docs.flowglad.com/agents/core-concepts Workspaces, memory, automations, proposals, and source-grounded analysis ## Workspaces A workspace is the operating context for a company or firm team. It holds the pages, connected systems, files, automations, and review history that Flowglad uses. ## Client Context Client context is the durable memory about an engagement: scope, operating history, working notes, source files, connected-system records, prior analyses, and approvals. ## Connected Systems Connected systems bring records and files from tools such as ledgers, payroll, banking, email, spreadsheets, and practice-management systems into Flowglad. ## Pages and Memory Pages organize client memory and analysis. They can be refreshed from connected sources and linked back to the records or files that support each claim. ## Automations Automations prepare recurring work from natural-language instructions and workspace context. They can read source data, draft analysis, and prepare next steps. ## Proposals and Reviewable Actions Flowglad can propose actions with rationale and supporting evidence. Teams decide what requires review before anything sensitive is posted, sent, or changed. ## Source-Grounded Analysis Analyses should connect conclusions to specific records, files, or pages so reviewers can inspect the evidence and audit trail. # Introduction Source: https://docs.flowglad.com/agents/introduction What is Flowglad? # What is Flowglad? Flowglad is the memory, intelligence, and action layer for companies, starting with Client Advisory Service agencies. It helps teams keep client context, connected-system records, source files, automations, and reviewable actions in one workspace. Workspaces, client context, connected systems, pages, memory, automations, proposals, and source-grounded analysis # Automations Source: https://docs.flowglad.com/automations Turn repeatable instructions into reviewable operational work Automations turn repeatable instructions into operational work. They use workspace context, connected sources, pages, and skills to prepare analysis or next steps on a schedule or in response to an event. An Automation is owned by one Space. Its Instructions may invoke a reusable Skill with `/`. A Skill does not schedule itself, and an Automation run does not automatically create an assigned Task. ## An automation can * Read from connected systems and source files * Combine source data with workspace context * Draft analysis, updates, or proposed actions * Record the run and its supporting evidence ## Reviewable actions When an automation would affect another system or produce a client-facing output, it should produce a proposal or reviewable result first. A reviewer can inspect the rationale, evidence, and intended action before approving it. ## Runs Each run should make its progress and outcome understandable. Runs provide the context needed to distinguish a successful action, a failed attempt, a pending review, and a result that needs follow-up. ## Create an Automation in a Space Automations belong to one Space. Open the intended **Space** → **Automations** → **New Automation**. Chat can explain this path and inspect existing Automations, but it does not create or save a new Automation for the user. ## Configure Triggers Under **Triggers**, choose **Add Trigger**. Real choices include **Schedule**, **File Upload**, and Connection event triggers that are shown for the Space. A Schedule supports the **Daily**, **Weekdays**, **Weekly**, and **Monthly** presets; set the intended time and timezone. ## Add Instructions and Connections Enter what the Automation should do in **Instructions**. Confirm the required provider appears under **Available Connections in \**. If the editor says **No active connections**, use **More prompt options** → **Add Connection**, finish the Space-scoped connection flow, and then return to the editor. ## Save the Automation Review the trigger, Instructions, and available Connections, then select **Save**. Saving an Automation does not create a Task, and a chat starter does not save an Automation automatically. ## Run and Inspect an Automation Open the Automation. **Overview** shows its configuration; **Runs** shows past and current runs. Select **Run** for a manual run when the action is available, then open the run to inspect its activity and result. Use the Space-level **Automations** → **Runs** view to review runs across that Space. ## Edit or Delete an Automation Open the Automation and edit its Instructions, Triggers, or available Connections, then select **Save**. Use **Delete** from the Automation's actions to stop all future runs when permitted; review the confirmation before deleting. ## Start From an Automation Template In the Space's **Automations** view, choose a template when the templates section is available and select **Add**. The template creates a draft in that Space. Review its Instructions, Triggers, and Connections, then select **Save**; adding the template does not run it. ## Programs When Available Some organizations show **Programs** under a Space's Automations. A Program is a structured, input-driven workflow. Open **Programs**, choose or create one, supply the requested inputs, and select **Run Program**. If the **Programs** view is absent, use the standard Automation flow. # Browser Use Source: https://docs.flowglad.com/browser-use Work with systems that do not expose a direct connector API Browser Use lets Flowglad work with websites and browser-based applications when a direct API connector is not available or does not cover the required task. ## Access modes Flowglad treats authenticated website access and unauthenticated website access as different product capabilities: * **Passwords** provide authenticated access for sites that require credentials. * **Website Access** provides access to a site without storing or using a password. Both capabilities can support browser work, but they have different security and lifecycle requirements. ## How browser work is reviewed Browser tasks should start from a defined destination and stay within the authorized site scope. Flowglad can gather information, prepare a draft result, or propose an action for review before anything sensitive is posted, sent, or changed. Browser activity should leave enough context for a reviewer to understand what was accessed, what the agent found, and which action—if any—was proposed. # Connectors Source: https://docs.flowglad.com/connectors Bring records and files from business systems into Flowglad Connectors bring records, files, and events from external systems into Flowglad. They give agents and teams a consistent way to work with client data across ledgers, payroll, banking, email, spreadsheets, practice-management tools, and browser-accessed applications. **Connectors** is the account-level catalog of supported providers and access products. A **Connection** is one configured provider instance that can be exposed to Spaces and used by their chats, Pages, and Automations. To configure one, see [Connections](/connections). ## Connector responsibilities A connector can provide: * Authorization and connection lifecycle management * Provider-specific reads and writes * Identity and scope information for the connected account * Normalized records and events for search, analysis, and automations ## Source-grounded work Connector data remains tied to its source. When Flowglad uses a connected record in analysis or an action proposal, reviewers should be able to understand which system supplied the evidence. ## Connection lifecycle Authorization and connection availability are separate concerns. Revoking an authorization can make its connections unavailable while preserving their configuration and space exposure, so reconnecting can restore access without rebuilding the workspace setup. Use the current **Browse** catalog under **organization menu** → **Connectors** as the source of truth for supported providers. A provider absent from Browse has no self-serve native Connector; [Connections](/connections#provider-is-not-in-browse) explains the bounded browser-access and file-based alternatives. # Communication channels and Spaces Source: https://docs.flowglad.com/guides/communication-channels-and-spaces Limit communication data to the people, channels, and conversations relevant to a Space Communication systems often contain conversations for many clients, teams, and topics. Before exposing a communication connection to a Space, limit the connection to the smallest useful set of messages or transcripts. This keeps the Space's context relevant and prevents unrelated communications from becoming available to its members, agents, pages, and automations. ## Choose the destination Space first Start with the access boundary. Identify which Space should use the communication data and confirm that its membership matches the people who should be able to read it. If the same communication system contains data for multiple clients or businesses, use separate scoped connections for their Spaces instead of exposing one broad connection everywhere. ## Filter before you expose Configure the connection's source scope before exposing it to a Space. Available controls depend on the provider: ### Slack Select only the Slack channels relevant to the Space. Avoid exposing organization-wide or cross-client channels when the Space serves one client or business. ### Gmail Limit included messages using one or more of these criteria: * Contacts and email domains * Gmail labels * Text found in a message's subject or body ### Outlook Limit included messages using one or more of these criteria: * Contacts and email domains * Outlook folders * Text found in a message's subject or body ### Fathom and Fireflies Limit meeting transcripts by participant email address or domain. For Fireflies, you can also match text in the meeting title. When a provider supports a historical import window, select only the period the Space needs. Review filters carefully before exposing the connection. A broad domain, shared folder, channel, or text rule can include conversations beyond the intended client or business. ## What exposure enables After you expose the scoped connection, its included content can be used by: * Agents working in the Space * Chats started in the Space * Page commands proposed by Agents and Automations * Automations that read connected content * Connection triggers available to automations The connection's configured scope remains the boundary. Content excluded by its filters should not become available merely because the connection is attached to the Space. ## Account for linked Spaces A parent Space can read content from its linked child Spaces. This includes communication data made available through a child's connections. Before exposing a communication connection to a child Space, review both the child's direct membership and any parent Spaces that link to it. Do not expose the connection if either audience is broader than the people who should see the included conversations. ## Before exposing a communication connection Confirm that: * The destination Space represents the correct client, business, or operational area. * Everyone with direct or linked access should be able to read the selected communications. * Provider filters include only the required channels, people, domains, folders, labels, meetings, or text matches. * The historical import window is no broader than necessary. * The connection owner understands which Space will receive access. After exposure, review the resulting content before relying on it in pages or automations. Tighten the connection scope if unrelated communications appear. # Pages Source: https://docs.flowglad.com/pages Create, edit, review, subscribe to, and manage Space-owned documents ## Create a Page Pages belong to one Space. Open the intended **Space** → **Pages** → **New Page**, enter the title, choose the Space, and select **Create**. Open the new Page to add content. ## Edit or Update a Page Use the Page's **Content** tab to read it. In the Page actions, choose **Edit Page Body** when available; direct content edits autosave. Agents and Automations can also create or edit Pages through reviewed command nodes. ## Page History and Subscription Open **Page History** to inspect prior Page revisions. Use **Subscribed** or **Not Subscribed** in the Page actions to opt into or out of its update notifications. ## Copy, Rename, Move, or Delete a Page The Page actions include **Rename**, **Copy Page Contents**, **Move to Space**, and **Delete** when permitted. **Copy Page Contents** copies the current document text; it does not duplicate the Page. Moving a Page changes its Space access. Deleting removes the Page from active lists; confirm the intended Page before selecting **Delete**. # Security Source: https://docs.flowglad.com/security Understand how Flowglad isolates data, controls access, and keeps actions reviewable Flowglad treats security as a first-class concern. Visit the [Flowglad Trust Center](https://trust.flowglad.com) to review our security policies and learn more about how we protect your data. We expect to complete our SOC 2 observation period in early November 2026, and HIPAA compliance is in progress. This page explains how Flowglad builds security into each part of the product: isolating data between Spaces, limiting access to connected systems, enforcing role-based permissions, requiring approval for external actions, and preserving an auditable record of activity. ## Isolated Spaces Spaces are isolated, access-controlled silos. A chat, automation, or agent working in one Space can only use the pages, files, connections, and other context available to that Space. It cannot access data from another Space unless that data has been explicitly made available through a supported feature such as [linking Spaces together](/spaces#linking-spaces-together). This isolation lets you organize an entire Flowglad organization into separate access boundaries. Work for one client, business, project, or internal team does not become available in another Space by default. ## Connection Ownership and Scoped Access Connecting an external account to Flowglad does not automatically expose its data to any Space. Only the connection owner can expose that connection to a Space or change the data included by its scope. Organization Admins can disconnect a connection, but they cannot expose it, edit its scope, or expand its access. Many connectors let the owner limit which records a connection makes available: | Connector | Available scope controls | | --------------- | ------------------------------------------------------- | | Slack | Channels | | Microsoft Teams | Channels (coming soon) | | Fireflies | Participants, participant domains, and meeting titles | | Fathom | Participants, participant domains, and meeting titles | | Gmail | Contacts, domains, labels, subject text, and body text | | Outlook | Contacts, domains, folders, subject text, and body text | One authorized account can support multiple independently scoped connections. For example, you can authorize one inbox, create a separate filtered connection for each client, and expose each connection only to that client's Space. Each Space sees its configured slice of the inbox rather than the entire account. For guidance on communication data, see [Communication channels and Spaces](/guides/communication-channels-and-spaces). ## Role-Based Access Control Flowglad applies permissions at both the organization and Space levels. Organization roles are Organization Owner, Organization Admin, and Organization Contributor. Organization Owners and Admins can oversee the organization and access every Space. Other organization members cannot see a Space unless they are directly added to it. Within a Space, a member can be a Space Owner, Space Contributor, or Space Viewer. Space Owners and Contributors can work with the Space's contents. Space Viewers can read available content but cannot change pages or files, manage automations, approve or reject automation runs, add connections, or create connection requests. See [Membership and roles](/spaces#membership-and-roles) for the complete permission comparison. ## Human Approval for External Actions Agents and automations cannot change data in a connected external system by default without human approval. When proposed work would post, send, update, or delete external data, a reviewer must approve or reject the action before Flowglad executes it. The connection owner can explicitly allow selected categories of actions to run autonomously for that connection. These permissions are configured per connection, so enabling an action for one connection does not grant the same authority to other connections or Spaces. ## Auditability Flowglad maintains an organization-wide audit log of activity across users and Spaces. This creates a record of who performed an action, where it occurred, and what changed, helping administrators investigate events and understand how work and data move through the organization. Organization admins can access it in [Settings](https://dashboard.flowglad.com/settings/audit). The organization audit log in Flowglad Settings, showing activity by time, actor, event, and subject. You can filter the audit log granularly by user, space, connector, event type, and over 50 more filterable parameters. # Skills Source: https://docs.flowglad.com/skills Create reusable instructions for chats and automations Skills are reusable packages of instructions and optional supporting files. They let your team define a repeatable way to complete a task once, then apply it consistently across Flowglad. Each Skill has a name, a slash-command slug, a description, and instructions written in Markdown. Supporting files can provide additional context or resources needed to follow those instructions. ## Use Flowglad as your team's Skill library Flowglad keeps each Skill as a versioned package. Publishing a change creates a new revision instead of replacing the previous package in place. Organization admins can open a Skill's **History** to inspect its revisions, compare changes, restore an earlier revision, or discard a draft when those actions are available. This gives your team one governed place to maintain reusable instructions while preserving which version was active at a given time. Draft and rejected revisions do not replace the active version. ### Manage Skills through MCP After you connect the Flowglad MCP server, an agent can inspect and manage your organization's Skill library for you: * `skills.list` returns the Skills visible to the connection. * `skills.get` returns the latest and active revision metadata for one Skill. * `skills.create` submits a new Skill package. * `skills.create_candidate` submits a new revision of an existing Skill. * `skills.publish_revision` verifies and publishes a deferred revision. Creating or updating Skills requires the `skills:write` permission on both the teammate's organization membership and the MCP connection's grant. If you add the permission after connecting the server, reconnect Flowglad MCP and authorize `skills:write` so the write tools become available. **Permissions:** Admins have Skill authoring access by default. To give a Contributor the same access, open **Settings** → **Team**, select the teammate, and enable **Skill Authoring**. This grants permission to create and update organization Skills without making the teammate an admin. ## Load Flowglad MCP Skills into your agent The Flowglad MCP server advertises `io.modelcontextprotocol/skills` during MCP initialization. This tells compatible clients that the server implements the agent Skill methods `skills/list` and `skills/get`. Each returned Skill includes `skill://` resource URIs and content digests; clients can retrieve the files with `resources/read`. Connecting the server does not guarantee that a client will call `skills/list` or install the returned packages. Client support varies. Add a startup instruction to ChatGPT / Codex or Claude when you want the agent to refresh the Flowglad registry at the beginning of each session. **MCP naming:** The names are intentionally different. `skills.list` with a dot is a Flowglad tool for your organization's versioned Skill records. `skills/list` with a slash is an MCP protocol extension method for discovering agent-facing Skill packages. ### Add the startup instruction Create the destination directory once before starting a new session, then add the matching instruction block below. #### ChatGPT / Codex Create the ChatGPT / Codex destination directory with `mkdir -p ~/.agents/skills`. Put the following block in `~/.codex/AGENTS.md` to apply it to every project, or in a repository's `AGENTS.md` to share it with that repository's team. ```markdown AGENTS.md theme={null} ## Flowglad MCP Skill bootstrap At the start of every new session, before handling the first task: 1. Confirm that the Flowglad MCP server is connected. 2. Refresh the agent Skill catalog from Flowglad. Prefer the advertised `skills/list` MCP extension method. If the client does not expose that method directly, use the Flowglad server's `resources/list` method and select resources whose URIs begin with `skill://flowglad/`. 3. For every returned Skill, retrieve its manifest with `skills/get` when available, then read each listed resource with `resources/read`, beginning with `SKILL.md`. 4. Synchronize the package into `~/.agents/skills//`. Compare the returned content digests and rewrite only new or changed Flowglad-managed files. Never overwrite or delete unrelated local Skills. 5. Treat the refreshed Flowglad package as the source of truth for this session. Make the synchronized Skills available for automatic matching and explicit `$skill-name` invocation. 6. If this ChatGPT / Codex client cannot call the Skill or resource methods, report that limitation once and continue without claiming that the registry was refreshed. ``` #### Claude Create the Claude destination directory with `mkdir -p ~/.claude/skills`. Put the following block in `~/.claude/CLAUDE.md` to apply it to every project, or in a repository's `CLAUDE.md` to share it with that repository's team. ```markdown CLAUDE.md theme={null} ## Flowglad MCP Skill bootstrap At the start of every new session, before handling the first task: 1. Confirm that the Flowglad MCP server is connected. 2. Refresh the agent Skill catalog from Flowglad. Prefer the advertised `skills/list` MCP extension method. If the client does not expose that method directly, use the Flowglad server's `resources/list` method and select resources whose URIs begin with `skill://flowglad/`. 3. For every returned Skill, retrieve its manifest with `skills/get` when available, then read each listed resource with `resources/read`, beginning with `SKILL.md`. 4. Synchronize the package into `~/.claude/skills//`. Compare the returned content digests and rewrite only new or changed Flowglad-managed files. Never overwrite or delete unrelated local Skills. 5. Treat the refreshed Flowglad package as the source of truth for this session. Make the synchronized Skills available for automatic matching and explicit `/skill-name` invocation. 6. If this Claude client cannot call the Skill or resource methods, report that limitation once and continue without claiming that the registry was refreshed. ``` You can ask ChatGPT / Codex or Claude to add the appropriate block to its own user-level instruction file. Review the proposed edit before accepting it because that file affects future sessions. The instruction is a best-effort agent bootstrap; if your environment must refresh Skills deterministically, implement the same synchronization in a trusted `SessionStart` hook or your MCP client integration. ## Where Skills are used Invoke an enabled Skill with its `/` in: * Space chats * Automation instructions You can add request-specific context after the slash command. Flowglad combines that context with the Skill's reusable instructions for the current task. Only Skills available in the current organization and Space context can be invoked. ## Creating and maintaining Skills Open the **organization menu** → **Skills** → **New Skill**. In the **Skill** tab, enter **Name**, **Slug**, optional **Description**, and the reusable instructions in **Markdown**. Use the **Files** tab for any supporting package files, then select **Create Skill**. The Slug uses lowercase letters, numbers, and hyphens, begins with a letter or number, and is what users type after `/`. Creating or editing a Skill produces a draft. On the Skill detail page, edits autosave; select **Publish Draft** to verify and publish the draft. If verification fails, use the displayed diagnostics to correct the draft and publish again. Use **History** to inspect revisions, restore a superseded revision, or discard a mutable draft when those actions are available. **Disable Skill** removes it from chat and Automation resolution without deleting revision history; **Enable Skill** makes it available again. ## Invoke a Skill In the chat composer, type `/` and choose an available Skill, or type its exact `/`. Add the request-specific context after the slash command. The same slash command can be included in Automation definitions. Only enabled, available Skills appear for the current context. If the product presents a **Run skill** confirmation card, review the inputs and confirm it there; that one-off run flow is not available in every organization. ## Create or edit a Skill with chat In a Space chat, ask chat to create or edit a Skill. Review the proposal, select **Start Skill-work**, follow the activity, and use **Save Skill and Enable** when the result is ready. ## Start from a Skill template The **Skills** page includes **Skill Templates**. Search or filter the catalog, preview a template, and select **Copy Skill**. The copy becomes an organization Skill that can be edited and published like any other Skill. ## Skills and Automations A Skill defines how to perform reusable work. It does not decide when that work runs. Use an Automation when work needs to run on a schedule or in response to an event. An Automation can invoke one or more Skills so the same process can be reused across recurring work and chats. # Spaces Source: https://docs.flowglad.com/spaces Isolate client context, control access, and organize operational work Spaces are isolated, access-controlled silos where your team organizes work for a client, business, or operational area. Each Space keeps its context and resources separate from every other Space unless you explicitly connect them. Use a Space when its contents should share one access boundary and one working context. ## Navigate a Space A Space's current tabs are **Pages**, **Chats**, **Automations**, **Files**, and **Linked** when link access is available. Open **More Space actions** → **Connections** for the Space's Connections. Pages, Files, Connections, and Automations shown there are scoped to that Space; a chat started inside it uses that Space as context. ## Create, Rename, or Delete a Space Select **New Space** in the sidebar, enter **Space Name** in **Create a Space**, and create it. Use **More Space actions** on an existing Space to **Rename** or **Delete** it when permitted. Deleting a Space removes its memberships and exposure settings and cannot be undone. Confirm the intended Space before using **Delete Space**. ## What lives in a Space A Space contains the resources that people and agents use to complete work: * Pages that preserve context, analysis, and working knowledge * Files used as source material * Connections to external systems * Automation runs * Chats grounded in the Space's available context Connections are not available to a Space by default. You must explicitly expose each connection before its contents can be used there. ## Membership and roles Membership determines what each person can see and change within a Space. The following table compares the actions available to each Space role. | Permission | Space Owner | Contributor | Viewer | | --------------------------------- | :---------: | :---------: | :----: | | View Space content | ✓ | ✓ | ✓ | | Create and edit pages | ✓ | ✓ | ✕ | | Add and manage files | ✓ | ✓ | ✕ | | Create and edit automations | ✓ | ✓ | ✕ | | Approve or reject automation runs | ✓ | ✓ | ✕ | | Add connections | ✓ | ✓ | ✕ | | Create connection requests | ✓ | ✓ | ✕ | ### Organization Owners and Admins Organization Owners and Admins are automatically members of every Space and have edit access. They can oversee work across the organization without being invited to each Space individually. ### Manage Space Members Open the Space and choose **Manage Space Members**. Members with the required permission can invite organization members, change Space roles, and remove access. A user who can read the Space may still lack permission to manage its members, Connections, Files, Pages, Automations, or links. ## Connections A Space cannot access an organization's connections until they are explicitly exposed to it. This prevents unrelated Spaces from seeing connected records by default. A connection owner can expose their connection directly. A Space Owner or Contributor can also request access from the connection owner. The connection remains unavailable until the owner approves the request and exposes it to the Space. Once a connection is exposed, its configured data scope becomes available to the Space's agents, chats, pages, and automations. Supported connection triggers also become available when you configure an automation. Communication connections can contain conversations involving many clients, teams, or sensitive topics. Configure a narrow source scope before exposing one to a Space. See [Communication channels and Spaces](/guides/communication-channels-and-spaces). ## Linking Spaces Together Linked Spaces provide one-way visibility from a parent Space into one or more child Spaces. Use links when work must remain separated at the child level but another Space needs consolidated visibility. When a parent Space links to a child Space: * Members of the parent can read the child's contents. * The child cannot see the parent's contents. * One child cannot see another child through their shared parent. * Linked visibility continues through additional child links. Linked access is read-only. To modify a page, file, automation, connection, or other resource in a child Space, a person must also be a direct member of that child Space with the required role. Creating a link requires link-management access in both Spaces. Removing a link requires link-management access in the parent Space. Open the Space → **Linked** to review its Linked Spaces. Use the visible add or remove controls to change links when permitted. Linking does not move or merge the source Space. Because links affect inherited access, confirm both the source and destination before changing them. ### Example: A Client with Multiple Businesses Suppose your firm manages a client's personal finances and six separate businesses. Create an individual Space for the client and each business so their records, files, and automations do not become commingled. Your management team can then use a parent Space linked to all seven child Spaces. The parent provides consolidated visibility into customer sentiment, team efficiency, and emerging issues while each child's working context remains isolated. ### Example: An Admin Space Overlooking Multiple Projects Suppose your organization runs several projects, each with its own team, files, pages, connections, and automations. Create a separate Space for each project so its working context remains isolated from unrelated work. Create an Admin Space and link each project Space as a child. The Admin Space gives leadership a consolidated view of project status, blockers, team activity, and emerging risks. Project teams cannot see the Admin Space or one another's Spaces through these links, and members of the Admin Space need direct membership in a project Space to modify its contents.