Workspace & Projects#
The workspace is your global workspace. It contains all of your projects (brands), each isolated with its own brand identity, social channels, and analytics.
Workspace
One workspace per user account. Contains all your projects. Linked to a pricing plan.
Project
Represents a brand or client. Each project has its own brand identity, social accounts, content, library, settings and automations.
Active Project
Only one project is active at a time. The project switcher (logo top-left of the app) allows you to toggle between projects. The active project defines the context for all operations.
Creating a project & switching between them
| Section | Role | Configuration |
|---|---|---|
| Vibe | Conversational AI brain: chat, generate, publish, ask anything | None |
| Studio | Flyer and video generation | Brand identity required |
| Library | All generated & uploaded media in one place | Automatic |
| Automations | Recurring workflows (Monday morning, etc.) | Manual configuration |
| Inbox | Incoming comments + auto-reply. Comment replies on Instagram, Facebook, and LinkedIn; DMs on Instagram and Facebook only (LinkedIn has no public API for DMs), TikTok has no public reply. | Webhook + OAuth |
| Posts | Draft and published content list | Automatic |
| Schedule | Publish queue and calendar | Social accounts required |
| Campaigns | Ad campaigns (Google Ads, Meta Ads), email and SMS, with their Analytics tab | Provider configured |
| Marketplace | Discover and hire creators | None |
| Settings | Brand identity, social accounts, Turbo, billing | Mandatory onboarding |
For agencies and enterprises (Agency and Enterprise plans), Gliiz offers BYOS (Bring Your Own Storage) via Google Drive. By connecting your Google Drive account in Project Settings (Accounts tab), all generated assets, flyers, images, and videos, are automatically and instantly synced to a dedicated folder named 'Gliiz AI - [Project Name]' in your cloud.
Invite an Admin or an Editor#
Team is managed both at the account level (Team tab on the Projects page /workspaces) and directly inside each project (Settings → Team tab, strictly reserved for the Owner and Admins; hidden from Editors). Every seat you invite draws from one shared, account-wide pool.
Owner
The account creator. Always has full access to every project, can't be removed or reassigned a role.
Admin (account-wide)
Full operational access to every project the owner has, present and future. Invited from the Team area without mandatory per-project scoping. By default, an Admin cannot delete or transfer a project (the Settings "Danger" tab remains hidden). However, the owner can explicitly grant these two sensitive scopes (delete_project and transfer_project) upon invite or edit. Billing and global account settings remain strictly reserved for the owner.
Editor (per-project)
Full access to exactly one project, chosen at invitation time create and manage its content, automations, brand and editorial. Access is segmented by scope: three are granted by default (content, automations, editorial); two are opt-in and sensitive (publish & connect accounts, private inbox), toggled with checkboxes at invite time. Members holding the automations scope can also review and approve content items in the collaborative approval queue. If the Editor already has their own account, the shared project appears in their own workspace with a "from workspace X · Editor" badge; all work draws from the inviting owner's credit pool, and the owner's private usage/credit figures stay hidden from them.
| Detail | How it works |
|---|---|
| Seat pool | One shared cap per account: the owner counts as the first seat, then every distinct Admin or Editor (active or pending) counts as one more, regardless of how many projects they touch. |
| Extra seats | Run out of seats on your plan? Buy more anytime from the Marketplace no plan upgrade required. |
| Invitation | Invitations can be sent either from the global Team area (/workspaces) or directly from project settings (Team tab, reserved for the Owner and Admins). Specify an email, a role (Admin with optional sensitive scopes, or Editor with project selection and access scopes). An email invite is sent; clicking it creates their account and grants access immediately. |
| Permission scopes | An Editor's access is segmented: content, automations and editorial are granted by default; publishing/connecting accounts and the private inbox are opt-in, sensitive checkboxes (they expose OAuth tokens and DMs). The owner or an Admin manages them. Members holding the automations scope can also review and approve items in the collaborative approval queue. Each scope also carries its read surfaces: the project's Analytics follow the content scope, the automation approval queue follows automations, and the Inbox auto-reply knowledge base follows inbox. |
| Shared billing | Everything a member generates on a project is billed to and capped by the project OWNER's credit pool not the member's own account. Attribution is kept per action. |
| Traceability | The Team tab shows each member's monthly credit total (with a colour), a per-member credit history down to each generated asset, and an Activity log of sensitive non-credit actions (renames, brand config, member changes). These figures are visible to the owner and Admins only. |
| Owner-only actions | Managing billing, subscriptions, and global account settings is strictly reserved for the account owner. Project deletion and transfer are disabled by default for collaborators; however, the owner can explicitly grant the sensitive scopes 'delete_project' or 'transfer_project' to an Admin (which unlocks the respective actions in the Settings Danger tab). Editors can never delete or transfer a project. |
| Managing a member | Resend a pending invite, adjust scopes (via the 'Edit permissions' action), or remove access from the action menu on their row. The Owner row has no action menu. |
Security Scopes: Editor vs Administrator#
Gliiz applies the principle of least privilege. Every collaborator receives permissions tailored strictly to their responsibilities. Sensitive actions (direct social network access, confidential direct messaging, project deletion, or ownership transfer) are isolated and require explicit opt-in.
1. Per-Project Scopes (Editor Role)
When inviting an Editor to a project, three fundamental scopes are granted by default to enable immediate collaboration. Two sensitive scopes require explicit opt-in checkboxes from the owner or admin.
| Scope | Status | Granted Surfaces & Actions | Security Rationale |
|---|---|---|---|
Content content | Included by default | Create, edit and delete visuals, flyers, carousels, videos and VIBE. View project performance analytics. | Creative work isolated to the project. Grants no access to social accounts or private messages. |
Automations automations | Included by default | Create, configure and activate automation workflows. Review, approve or reject posts in the collaborative approval queue. | Controls pre-publication logic inside Gliiz. Live delivery to social channels additionally requires the publish scope. |
Editorial & brand editorial | Included by default | Configure brand identity: Brand Voice, typography, colour palettes, logos and guidelines, the art direction, as set at onboarding. | Ensures brand consistency and guides AI generation without exposing external resources. |
Publishing & accounts publish | Sensitive · Opt-in | Connect/disconnect social accounts (LinkedIn, Instagram, TikTok, Facebook, X, etc.) and publish live or scheduled posts. | Sensitive (Opt-in): accesses the owner's OAuth tokens and allows broadcasting content publicly to official channels. |
Inbox inbox | Sensitive · Opt-in | Read and reply to direct messages (DMs), comments, trigger AI replies, and edit the auto-reply knowledge base. | Sensitive (Opt-in): grants access to confidential, private conversations with prospects and customers. |
2. Admin Sensitive Permissions (Account-wide)
An Account Admin holds operational access across every project on the account by default. However, the two critical and destructive actions below remain strictly denied until the owner explicitly grants these scopes.
| Permission | Default Status | Unlocked Action | Impact & Risk Level |
|---|---|---|---|
Project deletion delete_project | Disabled by default | Unlocks the permanent project deletion button in the project Settings Danger tab. | Critical: irreversible action that erases all project data, media, videos, automations and statistics. The Danger tab remains hidden from unauthorized Admins and Editors. |
Project transfer transfer_project | Disabled by default | Unlocks transferring project ownership to another registered user in the project Settings Danger tab. | Critical: legally passes project ownership to a third party. The project permanently leaves the original owner's account. |
💡 Inheritance rule: The Owner implicitly and permanently holds all scopes across every project on their account. Admins hold all daily operational permissions, while Editors are strictly scoped to their assigned project and granted scopes. The two destructive actions (project deletion and transfer) are never accessible to Editors under any circumstance.
Annotations: say WHERE, not just what#
Feedback on a visual gets lost when it stays a sentence: "the logo is too small" says neither which one nor where. An annotation is a comment placed ON the image, at a precise point. Click the visual, write the remark: it appears as a numbered pin the creator finds at exactly the same spot, on their screen and on yours.
Where to annotate. In the Library, by opening a visual full screen. And in the review screen: a pending publication opens for review, where you annotate then decide without leaving the page. A badge on the thumbnail shows how many remarks are still open, so you never approve without knowing someone wrote to you.
If the visual is regenerated. The image changes, but the remark keeps its meaning. It is neither deleted nor left pointing at random: its pin is flagged as placed on an earlier version. The text stays readable, and you know what to do with it.
Who can annotate : The Owner, Admins, and Editors holding the Content scope. Replies are one level deep: a reply always attaches to the original remark, never to another reply. Marking a remark resolved removes it from the counter without erasing the exchange. Every new annotation notifies the team in real time, with no need to reopen the page.
Mentions and notifications beyond the app : Type @ while writing a remark to bring up the project's teammates and mention one. Beyond the live in-app notice (for anyone already working on that visual), three people get notified even while offline: the visual's author when a new thread opens on it, every participant in a thread when someone replies, and anyone mentioned with @. The notice goes out by email (in the branded template, in each person's own language) and, if their Telegram is connected through Turbo, by Telegram message, never to whoever just wrote the remark.
| Feature | Free | Starter | Pro | Agency | Enterprise |
|---|---|---|---|---|---|
| Projects | 1 | 3 | 10 | 30 | ∞ |
| Social Accounts | 1 | 5 | 20 | ∞ | ∞ |
| Generations/month | 3 | 160 | 500 | 1600 | ∞ |
| Auto-replies/month | 0 | 50 | 200 | 500 | ∞ |
| Automations | 0 | 3 | 10 | 30 | ∞ |
| Team seats | 1 | 1 | 2 | 5 | ∞ |
| Turbo flows / project | 0 | 1 | 2 | 5 | ∞ |
| API Access | ❌ | ✅ | ✅ | ✅ | ✅ |
| White-label | ❌ | ✅ | ✅ | ✅ | ✅ |
| BYOS Google Drive | ❌ | ❌ | ❌ | ✅ | ✅ |
Was this documentation helpful?