# AI Easy Apps documentation

Product reference for people and AI assistants. Review dates apply to each guide. This reference does not grant account access or authorise actions.

# What AI Easy Apps does

Understand the product, its building blocks and current boundaries.

Audience: Everyone

Reviewed: 2026-11-06

Canonical path: /docs/overview

## What you can build

AI Easy Apps helps you create and use data apps: structured tables, forms for capturing records, views for finding information, and workflows for repeatable actions. Examples include household inventories, customer records, task tracking and internal requests.

AI can help create an app and draft workflows. AI editing of existing apps is not available; use the supported manual editor controls for changes. You still review the result, configure access and test the process before other people rely on it.

## The building blocks

- An account holds the subscription, creator seats and shared allowances.
- A workspace groups apps and people within an account.
- An app contains tables, views, forms and related configuration. A table holds records; fields describe each record.
- A creator builds apps. An app role controls what a person can do inside a shared app. Billing authority does not automatically grant access to records.

## Choose your starting point

1. Start from a saved template when its tables and process fit your needs.
2. Use AI-assisted creation for a different structure. Describe the people, records and tasks involved.
3. Use Create Form for a standalone public questionnaire or intake form.
4. Test a small example with sample data, then share with the intended roles.

## Current boundaries

New calendar presentation, external calendar sync, availability and online booking are not offered in this release. Ordinary Date and DateTime fields and supported Today/Overdue filtering remain useful.

Do not assume every spreadsheet formula, integration or requested AI action exists. The guides distinguish supported behaviour from separate setup and current limits.

## Related guides

- [Create and test your first app](/docs/getting-started)
- [Create and publish a public form](/docs/forms)
- [Product glossary](/docs/glossary)

---

# Create and test your first app

Go from sign-in to a small app you can safely share.

Audience: App creators

Reviewed: 2026-11-05

Canonical path: /docs/getting-started

## Before you start

Sign in with Google or Microsoft. Select the account and workspace that should own the app. Creation needs an available creator seat, an eligible subscription or trial, and an app slot. AI-assisted creation also needs AI allowance.

For a company app, check that you are in the company workspace rather than your personal workspace.

## Build a small first version

1. Choose a saved template, or open app creation and describe one useful process.
2. Describe the tables, fields and relationships. Set currency and time-zone requirements where relevant.
3. Review the proposed design: names, required fields, relationships and intended screens.
4. Complete creation and read the setup tasks on Overview. A workflow may still need configuring in Logic & Flow.
5. Add sample records. Test both a missing required value and a valid save.

## Example brief

```text
Build a household maintenance app with Assets and Tasks. Each Task belongs to one Asset and has a title, due date, status and estimated cost. Show open and overdue tasks. Use ZAR for money. I will configure reminder emails after reviewing the app.
```

## Share after testing

1. Confirm saved records and lookup labels are correct.
2. Grant only the app access each person needs.
3. Test with a separate user, including a record that user should not see.
4. Remove or clearly label sample data before using real information.

## If creation is blocked

Check workspace, creator-seat assignment, subscription status and app slots separately from AI allowance. Saved templates do not use AI allowance, but the app still occupies a slot. A creator-seat problem is not solved simply by having spare app slots.

## Related guides

- [Use AI to create apps and workflows](/docs/ai-assistance)
- [Tables, fields and validation](/docs/tables-and-fields)
- [Business accounts, workspaces and creators](/docs/business-subscriptions)

---

# Use AI to create apps and workflows

Write useful creation prompts, review results and understand the shared allowance.

Audience: App creators and AI assistants

Reviewed: 2026-11-06

Canonical path: /docs/ai-assistance

## What AI assistance covers

AI-assisted app creation, chat and workflow creation share the account AI allowance. AI editing of existing apps is not available. Use the supported manual editor controls to change an existing app. Workflow setup happens in Logic & Flow after creation; mentioning an automation in the initial brief does not mean it is enabled.

## Write a clear brief

1. Explain the purpose and who will use the app.
2. List the records to store with non-confidential examples.
3. Describe relationships explicitly, such as one Customer having many Jobs.
4. Specify required fields, choice values, currency and access requirements.
5. Ask for a small first version, then review and test the generated app.

## Example creation brief

```text
Create a task tracking app with a Tasks table. Each task needs a title, due date and required Priority choice with Low, Normal and High. Show Priority in the form and list. Explain any additional setup I must complete.
```

## Review the result

Check generated fields, formulas, workflow recipients and permissions. AI output can be incomplete or mistaken. A suggestion is not proof that data was saved, a rule enabled or a connection authorised.

There is no general runtime AI writing action for generating arbitrary text while a saved workflow runs. AI-assisted workflow design and runtime AI processing are different capabilities.

## Allowance and retries

Each AI attempt counts, including automatic retries; one request can use multiple attempts. Failed attempts can also consume allowance. Usage is shared across the account and resets at the start of each UTC calendar month.

AI exhaustion blocks further AI requests. It does not itself disable existing apps or supported manual editing; subscription, permissions and other limits still apply.

## Give documentation to another AI

Open a guide as Markdown or download the complete text. These files describe the product; they do not grant account access or permission to act. Publishing them does not automatically connect them to the in-app assistant or guarantee external services have read the latest version.

```text
Use the attached AI Easy Apps documentation as the product reference. Explain the steps for my task and cite the guide titles. Distinguish documented behaviour from assumptions. If a feature is not confirmed, say so. Do not invent menu items or claim an action was completed.
```

## Related guides

- [Create and test your first app](/docs/getting-started)
- [Create workflows with AI or the editor](/docs/workflows)
- [Allowances and product boundaries](/docs/limits)

---

# Tables, fields and validation

Design clear records, choose field types and validate input.

Audience: App creators

Reviewed: 2026-11-05

Canonical path: /docs/tables-and-fields

## One kind of record per table

Use a table for each main entity, such as Customers, Jobs or Assets. Each row is a record; each field holds an attribute. Keep a stable key for relationships. A display label is not necessarily the stored identifier used by formulas or integrations.

## Choose field types

- Text for names, descriptions and identifiers that are not quantities.
- Number and Currency for quantities and money; keep the app currency consistent.
- Date and DateTime for dates and timestamps.
- Choice for controlled values, with a custom Other value where enabled.
- Boolean for yes/no, Rating for a score and User for a person.
- Lookup for a related record, Calculated for a formula, File or Image for an attachment.

## Configure and test

1. Open the table/schema editor and choose the table.
2. Add or edit the field type and display label.
3. Set required input and available length, minimum, maximum or pattern rules.
4. Set visibility deliberately; do not hide a required field people must supply.
5. Save, then test valid and invalid values in the record form.

## Defaults

Defaults initialise new-record forms. They do not rewrite existing records or replace values already supplied by a person or parent form. Supported tokens include {{TODAY}} and {{User.Email}}. Choose a default compatible with the field type.

## Example and precautions

Tasks might contain required Title text, a DueDate, a Priority choice and EstimatedCost currency. A blank Title should prevent a valid save; a completed form should create one record.

Structural changes can affect data, imports, formulas and workflows. Export important data before destructive changes. Changing a display label is not a data migration.

## Related guides

- [Lookups and linked tables](/docs/relationships)
- [Calculated fields and formulas](/docs/calculations)
- [Views, pages and appearance](/docs/views-and-navigation)

---

# Lookups and linked tables

Connect records while preserving ownership and access.

Audience: App creators

Reviewed: 2026-11-05

Canonical path: /docs/relationships

## A lookup is a relationship

A Job can reference a Customer and display its name without copying the Customer into every Job. The relationship uses the target identity; the readable label helps people select it.

## Configure a lookup

1. Create the target table and representative target records.
2. Add a Lookup field to the source table.
3. Select the target table and display column; configure available filters and additional displayed columns.
4. Save, create a source record and select an existing target.
5. Verify as both creator and restricted user.

## Related-record creation

Where a form offers creating a related record, wait for its save to succeed before relying on its selection. A cancelled or rejected save is not a completed related record. A pending approval may mean the target is not yet available.

## Cross-app linked tables

Cross-app access uses Linked Data and explicit grants. AI-generated designs do not authorise it. The source app still owns the table; a linked view is not a second owned copy.

Both the link grant and user permissions matter. Revoked grants or unreadable targets can make a previous relationship unavailable.

## Troubleshooting

A missing label can mean the target was removed, the link is incomplete or the user cannot read it. Verify intended access before broadening permissions. A lookup is not automatically a rollup or arbitrary cross-table formula.

## Related guides

- [Tables, fields and validation](/docs/tables-and-fields)
- [Calculated fields and formulas](/docs/calculations)
- [Business accounts, workspaces and creators](/docs/business-subscriptions)

---

# Calculated fields and formulas

Use supported expressions and verify their results.

Audience: App creators

Reviewed: 2026-11-05

Canonical path: /docs/calculations

## What a formula does

A Calculated field derives a value from the record and supported functions. This is a product formula language, not a complete Excel engine. Use actual field names; display labels and workflow substitutions are separate concepts.

## Add and test

1. Choose a Calculated field in the table editor.
2. Enter an expression using record fields. Bracketed references make names explicit.
3. Save and inspect values on known sample records.
4. Test blanks, zeros and invalid values before relying on the result.

## Example

```text
ROUND([Quantity] * [UnitPrice], 2)

Quantity = 3 and UnitPrice = 12.50 should produce 37.50.
```

## Supported functions

- Numbers: ABS, ROUND, MIN, MAX and SUM.
- Conditional/blank checks: IF and ISBLANK.
- Dates: TODAY, NOW, DAYS, YEAR, MONTH and DAY.
- Text: LEN, UPPER, LOWER and TRIM.

## Important distinctions

A formula computes a value; a workflow performs an action. Workflow values such as {{CURRENT.Title}} use different syntax.

Do not assume SUM scans every row in a table or an unlisted Excel function is supported. Test representative values and investigate errors rather than replacing them with guessed totals.

## Related guides

- [Tables, fields and validation](/docs/tables-and-fields)
- [Lookups and linked tables](/docs/relationships)
- [Create workflows with AI or the editor](/docs/workflows)

---

# Views, pages and appearance

Organise the interface without confusing layout with security.

Audience: App creators

Reviewed: 2026-11-05

Canonical path: /docs/views-and-navigation

## Views present records

A table stores records; a view presents them with a layout, visible columns, filters and sorting. Multiple views do not create extra copies of the records.

## Configure a view

1. Open Pages & Navigation.
2. Choose the table view.
3. Set the filter, sort field/direction and visible columns.
4. Save and reopen the runtime view.
5. Check records that should match and records that should be excluded.

## Example

For Tasks, make an Open Tasks view using the exact open status in your app. Sort by DueDate and show Title, DueDate and Priority. Test one open and one completed task. Use supported Today/Overdue filtering for date-based views.

## Appearance

Use appearance settings for branding. Configure dashboard or static landing-page content where offered. Save and check narrow and wide screens. Use labels that describe the tasks people need to complete.

## Security and limits

Hiding a field or filtering a view is not an access-control rule. People may reach permitted data through other views or exports. Configure permissions separately.

New calendar presentation and online booking are not offered in this release. A Date field does not create a calendar integration.

## Related guides

- [Tables, fields and validation](/docs/tables-and-fields)
- [Records, imports and exports](/docs/records-and-imports)
- [Allowances and product boundaries](/docs/limits)

---

# Records, imports and exports

Save reliable data, map imports and check exported results.

Audience: App users and data managers

Reviewed: 2026-11-05

Canonical path: /docs/records-and-imports

## Before changing data

Check the app, table and workspace. Role, record access and the owning account subscription determine whether a change is allowed. Validation and approval rules still apply.

## Create and edit

1. Open the table and record form.
2. Complete required fields and select lookup records.
3. Save and read the result: an approval request is not an applied data change.
4. Check the saved record in the table.
5. Confirm the result rather than assuming a closed dialog means success.

## Import a file

1. Open Import for the target table and select a supported CSV or Excel file.
2. Select the sheet where prompted and map source columns to fields.
3. Review required values, dates, numbers and lookup matching in the preview.
4. Choose unmatched-lookup handling only where offered.
5. Run the import and read the imported/skipped/error results. Reconcile accepted rows before retrying.

## Partial results and approvals

An import can accept some rows and reject others. Do not assume everything rolled back; repeating the file can duplicate accepted rows. Preserve the result and correct rejected rows first.

Some approval-controlled operations block import and direct you to a record form. Follow that path. Ordinary file imports do not promise to run record-created workflows for every row.

## Export

Use available CSV/Excel export or a configured snapshot destination. Confirm whether the chosen interface exports a table, filtered records or an app snapshot. Check row counts, IDs, dates and calculated values.

A downloaded file is a copy; editing it does not automatically change the app. Do not assume an export includes attachment binaries, permissions or everything needed to restore the app.

## Save failures

Read the exact validation/permission message. Check required fields, owning-account status and record allowance. After an uncertain response, check whether the record exists before repeating the action.

## Related guides

- [Request and review approval](/docs/approvals)
- [Storage, snapshots and connected destinations](/docs/storage-and-sync)
- [Allowances and product boundaries](/docs/limits)

---

# Create and publish a public form

Collect responses, attachments and optional Microsoft List deliveries.

Audience: Form creators

Reviewed: 2026-11-05

Canonical path: /docs/forms

## Public submission

A published form link allows submission without sign-in. Treat it as public access to submission, not permission to view app data. The form uses an app slot; responses use its record allowance.

## Create and publish

1. Choose Create Form, then Create blank form.
2. Add questions, required answers, branding and an optional welcome page.
3. Preview and save the private draft.
4. Publish and copy the public link. Later draft saves do not replace published questions until published again.
5. Submit a harmless test and check View responses.
6. Close to stop collection, or replace the public link to invalidate the old one.

## Question and attachment limits

Up to 40 questions are supported: text, number, date, choice and yes/no. Each question can allow one optional attachment. All attachments in one response must fit within 3 MiB combined. Accepted types are PDF, PNG, JPEG, WebP, TXT, CSV, DOCX and XLSX.

The creation screen and editor explain the shared attachment limit. Respondents see guidance before the questions, selected file sizes, the combined total and remaining space. An oversized selection shows a warning and blocks submission until files are removed or replaced. Answers remain in the open form while files are changed; this is not a promise of recovery after closing or refreshing the page.

For five photos, provide five attachment-enabled questions. Five 1 MB photos exceed the combined limit. Ask respondents to resize or compress images first; uploaded response images are not automatically compressed.

Attachments use the owner's connected storage. The public form link does not make files public. Check storage permissions and capacity before collecting real files.

## Microsoft Lists

After publishing, open Microsoft List in the editor, select the SharePoint site/List and map questions to compatible columns. This needs a Microsoft work or school connection with destination access. Required List columns need suitable required questions.

Each accepted entry creates a new item. Retries of the same entry are deduplicated; separate entries with identical answers remain separate. Old responses are not backfilled. Editing a response does not update its delivered item.

## Delivery recovery

Review delivery status before retrying. If column creation is unavailable, a List owner may need to create a Single line of text column named AIEasyAppsEntryId, maximum length 255, with unique values enforced, then reconnect.

Disconnecting stops pending delivery without deleting delivered items. Uploaded files are copied to the List item as native attachments and also remain in the form owner's document storage. The owner needs attachment write access. Delivery completes only after answers and all files are verified; retries resume the same item. Files receive a numbered prefix to keep duplicate names distinct.

## Expected result and exclusions

Verify the response in the app and any remote List item separately. AI question drafting and spreadsheet-to-form design are not offered in this release.

## Related guides

- [Records, imports and exports](/docs/records-and-imports)
- [Storage, snapshots and connected destinations](/docs/storage-and-sync)
- [Allowances and product boundaries](/docs/limits)

---

# Create workflows with AI or the editor

Configure triggers, conditions and actions, then verify the outcome.

Audience: App creators

Reviewed: 2026-11-05

Canonical path: /docs/workflows

## Before you begin

Open Logic & Flow. Identify the triggering table, matching conditions and intended action. Use harmless records and test recipients when verifying messages or data changes.

## Build with AI

1. Open the workflow AI assistant in Logic & Flow.
2. Describe event, table, conditions and action using real field names.
3. Review the proposal and warnings, especially recipients, targets and substitutions.
4. Apply the proposal and save app changes.
5. Trigger one controlled example and check Workflow Logs and the actual result.

## Trigger and action reference

- Triggers: record creation, update, deletion and scheduled daily evaluation.
- Conditions include equals, not equals, contains, greater/less than and supported date comparisons.
- Actions include email, updating/creating records, HTTP requests, fetching records and moving records.
- Availability and permission checks still apply. An action name is not authority for arbitrary external access.

## Example

```text
When a Tasks record is created and Priority equals High, send a test email with the task title to the test recipient I provide. Do not update other records.

Record substitution: {{CURRENT.Title}}
```

## Variables

Use the variable picker where available. {{CURRENT.Field}} refers to the triggering record. Supported lookup paths can follow relationships, but related records must exist and be readable. Verify recipients before sending. Never put credentials into prompts or ordinary record fields.

## Check and recover

Verify the saved rule and matching event. Read Workflow Logs and inspect the target record or mailbox separately. An absent log is not proof of success. Check for an existing result before repeating an uncertain send.

Daily evaluation is not an exact-time delivery guarantee. Avoid rules that repeatedly trigger each other. AI allowance does not promise unlimited workflow throughput or email delivery.

## Design versus execution

AI drafting consumes shared AI allowance. Running a saved ordinary workflow is separate. There is no general runtime AI writing action. Use Approvals Hub when a change must wait for sign-off.

## Related guides

- [Use AI to create apps and workflows](/docs/ai-assistance)
- [Request and review approval](/docs/approvals)
- [Troubleshoot a problem](/docs/troubleshooting)

---

# Request and review approval

Hold a data change until the required decisions are complete.

Audience: Creators, requesters and approvers

Reviewed: 2026-11-05

Canonical path: /docs/approvals

## Approval is not a status label

Approvals Hub configures processes for operations requiring sign-off. A pending request is separate from an applied table change. Final required approval must complete before application. Setting Status to Approved in an ordinary workflow is not a substitute.

## Configure a process

1. Open Approvals Hub with the required management role and a plan supporting approvals.
2. Choose the table and operation requiring approval.
3. Add steps and select eligible approvers.
4. Choose the available decision rule, such as all required approvers or a configured quorum.
5. Save and submit a harmless example through the normal form.

## Submit and decide

A submitted request does not mean the business record changed. Approvers use their Approvals page to review and decide. Check the history and final outcome.

Application can fail even after decisions if the record, permissions, subscription or capacity changed. A final decision is not enough to establish that the write completed.

## Test the journey

1. Submit a valid request and confirm it is pending.
2. Confirm the record has not changed prematurely.
3. Have required approvers decide using their own accounts.
4. Verify the applied result in the table.
5. Repeat with rejection and confirm the requested change was not applied.

## Troubleshooting

If an approver is missing, check app eligibility and process configuration. If a request is missing, check account, app and intended recipient.

The current editor uses configurable steps. Use supported request actions, not direct edits of internal approval records.

## Related guides

- [Create workflows with AI or the editor](/docs/workflows)
- [Records, imports and exports](/docs/records-and-imports)
- [Business accounts, workspaces and creators](/docs/business-subscriptions)

---

# Storage, snapshots and connected destinations

Understand where records and files go, and verify delivery.

Audience: App owners and data managers

Reviewed: 2026-11-05

Canonical path: /docs/storage-and-sync

## Different resources

Records, attachments, exported spreadsheets and connected Lists are different resources. A record save does not prove remote delivery completed. App access does not automatically grant cloud-file access, and file access does not grant app permissions.

## Configure and verify

1. Open Overview or Overview & storage for the app type.
2. Check the connected identity and storage location.
3. Where offered, choose a snapshot destination or connect the intended List and map columns.
4. Use an authorised test record or snapshot.
5. Read the result and open the destination to confirm the expected file or List.

## Snapshot versus maintained copy

A snapshot is a point-in-time copy. A maintained List destination can have different push/update behaviour. Read its configuration before pushing, especially where existing items can be updated or removed.

Do not assume connections are bidirectional, editing a cloud copy updates the app, or a spreadsheet is a complete restorable backup.

## Public forms are different

Form List delivery creates one item per new accepted entry. It does not backfill old responses, update delivered items from edited responses, or attach files directly to List items. Use the form guide for that workflow.

## Connection problems

Check the connection banner, permissions and error. Reconnect the intended account when prompted, then verify before retrying. Ownership changes and revoked provider access can affect delivery. Do not publish tokens or secret-bearing file links in support requests. Calendar connections are not offered in this release.

## Related guides

- [Create and publish a public form](/docs/forms)
- [Records, imports and exports](/docs/records-and-imports)
- [Troubleshoot a problem](/docs/troubleshooting)

---

# Personal accounts and subscriptions

Understand your workspace, plan and payment options.

Audience: Personal account owners

Reviewed: 2026-11-05

Canonical path: /docs/personal-subscriptions

## Your personal account

Personal plans begin with your own account/workspace and include one creator seat. Sharing an app is different from giving another person a creator seat or account-administration authority.

## Plan choices

Personal Trial lasts seven days. Personal Home and Personal Pro are paid plans. Use Pricing for current amounts and allowances rather than an old screenshot or AI answer.

Annual pricing offers twelve months for the price of ten monthly payments, paid upfront. Capacity stays the same and AI allowance renews monthly.

## Review your account

1. Open Manage Account and confirm its name.
2. Open billing to inspect plan, status, usage and trial details available to your role.
3. Check app slots separately from AI allowance. Templates use slots but no AI allowance.
4. Review the business model before placing company-owned apps in a personal workspace.

## Billing availability

This release directs paid customers to account billing and the platform administrator; paid self-service checkout is not yet enabled from Pricing. A displayed offer is not proof of payment or activation.

Review final amount, taxes, renewal and cancellation terms before payment. Do not assume a trial silently becomes paid.

## When access is limited

Check whether the owning account is active, its trial expired or an allowance is exhausted. AI exhaustion differs from an inactive subscription. Using another person's app depends on its owner and your granted access.

## Related guides

- [Business accounts, workspaces and creators](/docs/business-subscriptions)
- [Allowances and product boundaries](/docs/limits)
- [Use AI to create apps and workflows](/docs/ai-assistance)

---

# Business accounts, workspaces and creators

Separate subscription ownership, team management and app access.

Audience: Business owners and administrators

Reviewed: 2026-11-05

Canonical path: /docs/business-subscriptions

## Ownership boundaries

The account owns subscription and shared allowances. Workspaces organise teams and apps. App roles and record-access rules control data access. Another workspace does not multiply app or AI allowances.

## Account roles

- Account Owner has commercial and operational authority.
- Billing Admin manages eligible billing actions; this is not automatic record access.
- Account Admin manages permitted operational tasks such as members, seats and workspaces.
- Member uses the workspaces and apps granted to them.

## Creators and users

A creator seat permits eligible app creation. Account membership, workspace membership and app sharing are separate grants. External app users use selected apps rather than administer the company.

Use Roles for current app-role details. Do not infer access from an email domain, job title or billing role.

## Invite and assign

1. Confirm the active company account.
2. Open member management and select role and seat type.
3. Choose workspace access where offered and send the invitation.
4. The recipient accepts with the invited identity. Pending invitations can reserve seats.
5. Grant app access separately and verify with the recipient's account.

## Ownership and offboarding

Review owned apps and workspaces before removing a member or reclaiming their creator seat. Transfer ownership through the supported flow where required. Removing account access does not revoke every external connection or delete its files. Check company app inventory and sharing after changes.

## Plans

Business Trial lasts seven days and includes five creators. Starter includes three; Growth includes ten. Review assignments before moving from trial to Starter. Enterprise terms are agreed separately.

Use Pricing and account billing for current amounts and usage. Annual payment retains monthly AI renewal and the same capacity. Paid self-service checkout from Pricing is not yet enabled in this release.

## Related guides

- [Personal accounts and subscriptions](/docs/personal-subscriptions)
- [Allowances and product boundaries](/docs/limits)
- [Product glossary](/docs/glossary)

---

# Allowances and product boundaries

Separate plan quotas, AI usage and tested operating capacity.

Audience: Everyone

Reviewed: 2026-11-06

Canonical path: /docs/limits

## Apps and records

App slots count saved apps across account workspaces. They are reusable, not annual creation credits. Unused apps count. Deleting an app removes its data and frees the slot; an archive-and-restore entitlement is not promised.

Record allowance is per app across physically owned tables, not per table. Related records can use additional capacity. Linked views do not add another owned copy. Deleted rows do not consume active record allowance.

## Creators and AI

Creator seats control who can build; sharing allowances apply per app. Neither overrides permissions.

AI chat, app generation and workflow drafting share account allowance. Each attempt can count, including failures/retries. Renewal follows the UTC calendar month even with annual payment. Manual operation remains subject to subscription and permission checks.

## Capacity versus performance

Published record figures are configured allowances. Bounded staging checks exercised 100,000-row reads and complete CSV/Excel exports; they do not establish every integration, workload or concurrency level at that size.

Large-table launch capacity and final acceptance remain under review. Agree and test representative record widths, relationships, filters, exports and concurrent use before relying on a large app. Custom Enterprise terms are not unlimited infrastructure.

## Current exclusions

- New calendar presentation, sync, availability and online slot booking are not offered; ordinary date records remain usable.
- AI workflow design does not include a general runtime AI writing action.
- Public-form AI drafting and spreadsheet-to-form design are not offered.
- Paid self-service checkout and add-on purchases are not promised by the current Pricing page.
- An export or record count does not establish complete backup, disaster recovery or unlimited throughput.

## At a limit

Read the message and check the owning account. Do not delete business data merely to experiment with a quota. Export and review what must be retained before destructive action. Ask the account owner to review capacity.

## Related guides

- [Personal accounts and subscriptions](/docs/personal-subscriptions)
- [Business accounts, workspaces and creators](/docs/business-subscriptions)
- [Troubleshoot a problem](/docs/troubleshooting)

---

# Troubleshoot a problem

Find the cause and collect useful information without exposing private data.

Audience: Everyone

Reviewed: 2026-11-05

Canonical path: /docs/troubleshooting

## Check context

1. Record app, table and intended action.
2. Confirm signed-in identity, account and workspace.
3. Read the error and check whether the operation nevertheless completed.
4. Use a harmless example only if it will not duplicate a record, message or payment.

## Cannot create or see data

For creation, check creator seats, subscription/trial, app slots and separate AI allowance. A template failure is not necessarily an AI problem.

For missing records or lookup labels, check shares, row access, filters and target relationships. Missing data can be intentional access control; ask the owner to verify intended access.

## Save or import failed

Check required values, types, subscription, record allowance and approvals. Read partial-import results before retrying. If another user changed a record, refresh and reconcile rather than overwrite blindly.

## Automation or delivery failed

Check saved rule, event and conditions, then available Workflow Logs and the destination separately. For forms, inspect response and List-delivery status in the editor. Investigate uncertain sends before repeating them.

## Useful support details

- Expected and actual result.
- Time and time zone, app/table name and exact error.
- Reproduction steps with non-sensitive values.
- A screenshot of the control/error with private records and file links obscured.
- Whether one or several users are affected.

## Keep private information private

Do not share passwords, keys, tokens, card details, customer exports or secret-bearing URLs. An external AI should receive only information you are authorised to share. Use Help for the current support route.

## Related guides

- [Allowances and product boundaries](/docs/limits)
- [Records, imports and exports](/docs/records-and-imports)
- [Create workflows with AI or the editor](/docs/workflows)

---

# Data, storage and security

Where information is stored, how access works, and what Supabase and Vercel security attestations mean.

Audience: Everyone, account owners and security reviewers

Reviewed: 2026-11-05

Canonical path: /docs/data-and-security

## Where your information goes

AI Easy Apps uses several services with different responsibilities. Your records, uploaded files and downloaded exports do not necessarily live in the same place.

- Supabase hosts the PostgreSQL database used for account profiles, membership and sharing configuration, app definitions, application records, form responses and operational state such as approval and workflow information.
- Vercel hosts the web application and server-side request processing. Requests, uploads and responses can pass through this hosting environment; it is not just a place for public website images.
- Connected Google Drive, Microsoft OneDrive or SharePoint can hold attachments and exported files. The database holds file references and metadata such as name, provider, owner and size. App branding images can also be embedded in app configuration.
- Configured spreadsheet or Microsoft List destinations hold additional copies of the data sent to them. Downloaded exports are also copies on the recipient's device.

## Access to accounts, apps and records

Sign-in establishes identity. Account and workspace membership, creator seats, app roles and record-access rules then determine the actions available. A billing role does not automatically give someone access to every business record.

The application uses server-side permission checks and PostgreSQL row-level security for user-scoped record access. Hiding a field or filtering a view is presentation, not a substitute for those access rules.

Platform administration and authorised service operations are separate from ordinary app-user access. Row-level security does not mean that hosting operators or every privileged service identity are technically unable to access data.

- Grant the minimum app access each person needs and review it when people leave.
- Protect the Google or Microsoft identity used to sign in, including multi-factor authentication where available through that identity provider.
- Test sharing with a separate user rather than assuming the owner's view matches everyone else's.

## Files and public form links

Form attachments are uploaded through the application into the form owner's connected storage. In-app access to stored attachments checks sign-in, app and record access, and the stored file reference before retrieving the file. Provider permissions and external sharing links are separate controls.

A published public-form link allows people to submit without signing in. It does not grant access to the response table or make uploaded files public. Treat the submission link as something recipients can forward. Close the form or replace its link when collection should stop.

Removing a member, closing a form or deleting an app should not be treated as proof that every exported file, external List item or previously downloaded copy has also been deleted.

## Encryption and connection protection

The hosted application uses HTTPS. Its database connection code requires TLS certificate verification. The application also encrypts newly stored Google and Microsoft refresh tokens; these tokens let authorised features use connected storage without asking for a password on every request.

Supabase documents encryption at rest with AES-256 and TLS in transit. Vercel also documents encryption controls for its infrastructure. These provider statements describe their respective services; they are not a claim of end-to-end encryption between individual app users. Authorised application services must be able to process data to provide the features.

- [Supabase security and encryption](https://supabase.com/security)
- [Vercel security and compliance measures](https://vercel.com/docs/security/compliance)

## Supabase and SOC 2

Supabase states that it is SOC 2 Type 2 compliant and undergoes annual assessment. It also publishes ISO 27001 certification information. SOC 2 Type 2 reports assess the operation of controls over a period of time; they are not a guarantee that an application can never suffer a security incident.

For procurement or a formal security review, use Supabase's current report and certificate, including their scope and reporting period. Report access can depend on the provider's plan or request process.

- [Supabase SOC 2 compliance](https://supabase.com/docs/guides/security/soc-2-compliance)
- [Supabase security and certification information](https://supabase.com/security)

## Vercel and SOC 2

Vercel publishes a SOC 2 Type 2 attestation covering Security, Confidentiality and Availability, and ISO 27001:2022 certification. Its official compliance page and Trust Center provide current information and access instructions.

Vercel secures its hosting infrastructure; AI Easy Apps remains responsible for its application code, configuration, permissions and handling of customer information.

- [Vercel compliance and attestation scope](https://vercel.com/docs/security/compliance)
- [Vercel shared responsibility model](https://vercel.com/docs/security/shared-responsibility)
- [Vercel Trust Center](https://security.vercel.com/)

## What provider certifications do not mean

Using Supabase and Vercel does not give AI Easy Apps its own SOC 2 attestation or ISO 27001 certification. This guide makes no claim that AI Easy Apps has independently obtained either.

Provider certifications also do not automatically establish that your particular use meets GDPR, POPIA, HIPAA or another legal or contractual requirement. The data you collect, access settings, processing purposes, provider agreements and operating practices all matter. Confirm the requirements for your intended use with the account owner and platform team.

## Hosting regions and international processing

The current application deployment configuration targets Dublin, Ireland for Vercel application functions. Supabase hosts the primary database in the region selected for its project; confirm the current production database region with the platform team before relying on a contractual residency requirement.

A function or database region is not a promise that every copy and processing step stays in that country. Content delivery, provider operations, logs, connected Google or Microsoft services, AI processing and user downloads may involve other locations. Supabase explicitly distinguishes regional database hosting from other processing outside that region.

For a residency review, ask for the current production database and compute regions, backup arrangements, connected-storage tenant locations, AI services and applicable data-processing agreements together.

- [Supabase data residency and transfers FAQ](https://supabase.com/legal/privacy-resources/data-residency-and-transfers-faq)
- [Vercel shared responsibility and region selection](https://vercel.com/docs/security/shared-responsibility)

## How AI assistance processes information

AI requests send your prompt and relevant feature context to the configured AI service. Depending on the feature, that context can include conversation history, app structure, field names and examples or data you put in the conversation. The implementation supports Google Gemini and an optional xAI provider path; availability depends on deployment configuration.

Do not assume prompts stay only in Supabase or that all AI processing occurs in the database region. Use non-sensitive examples where possible, and include only information you are authorised to share. This guide does not promise zero provider retention or exclusion from model training; confirm the applicable provider configuration and contractual terms before sharing sensitive information.

## Exports, deletion and retention

Export the records you need using the supported CSV, Excel or snapshot features, and check the result. An export is not necessarily a complete backup of app configuration, permissions, attachments and linked destinations.

Application records, external files, delivered List items, logs and provider backups have different lifecycles. Deleting a record from a view does not establish immediate erasure from every system or backup. This guide does not promise a universal retention period, backup schedule or recovery time.

For account closure, personal-data requests, retention requirements or an incident, use Help to contact the platform team. Explain the account, app and data category involved without sending passwords, access tokens or unnecessary record contents. Confirm the scope of any deletion and retention arrangement before relying on it.

## Review date and further questions

Provider statements and product behaviour were reviewed on 5 November 2026. Follow the official source links for current report availability and scope. This guide explains the product architecture and practical controls; it does not replace a privacy notice, contractual data-processing agreement or a security assessment for your organisation.

## Related guides

- [Storage, snapshots and connected destinations](/docs/storage-and-sync)
- [Create and publish a public form](/docs/forms)
- [Business accounts, workspaces and creators](/docs/business-subscriptions)

---

# Google and Microsoft sign-in and password recovery

Choose the right identity, recover a forgotten password and resolve common sign-in problems.

Audience: Everyone and IT support teams

Reviewed: 2026-11-05

Canonical path: /docs/sign-in-and-passwords

## How sign-in works

Choose Sign in with Google or Sign in with Microsoft on the login page. Google or Microsoft verifies your identity and returns you to AI Easy Apps. For these methods, there is no separate AI Easy Apps password to create or reset, and AI Easy Apps does not receive your Google or Microsoft password.

Google includes personal Google accounts and managed Google Workspace accounts. Microsoft includes personal Microsoft accounts and work or school identities used with Microsoft 365. Your organisation can restrict third-party applications or require administrator approval.

## Choose the identity that has access

If the app says the email is registered with the other sign-in option, use the original provider. Do not assume Google and Microsoft accounts merge automatically.

1. Use the provider and email identity you originally used, or the identity named in your invitation.
2. If Microsoft asks whether this is a personal or work/school account, choose the identity your organisation invited. Similar email addresses do not guarantee the same identity or permissions.
3. Complete the provider's verification and consent screens. Review requested permissions: connected storage features need permissions beyond basic sign-in.
4. Return to AI Easy Apps and select the intended account and workspace. Signing in does not itself grant app access or a creator seat.

## Forgot your Google password

Use Google's account recovery process and follow its identity checks. For a managed work or school account, contact your Google Workspace administrator if recovery is unavailable. AI Easy Apps support cannot reset the Google password or bypass Google's verification.

- [Google: recover your account or Gmail](https://support.google.com/accounts/answer/7682439)

## Forgot your Microsoft 365 or Microsoft password

For Microsoft 365 work or school accounts, use Microsoft's work/school password reset instructions. Self-service recovery requires your organisation to enable it and suitable security information. If it is unavailable or your verification method is lost, contact your organisation's IT administrator.

For a personal Microsoft account, use the personal-account recovery instructions. AI Easy Apps support cannot reset either Microsoft password or bypass multi-factor authentication. After recovery, return to AI Easy Apps and sign in again with the same identity.

- [Microsoft: reset a work or school password](https://support.microsoft.com/en-us/accounts-billing/work-school/reset-your-microsoft-work-or-school-account-password-using-security-info)
- [Microsoft: reset a personal account password](https://support.microsoft.com/en-us/accounts-billing/manage/reset-a-forgotten-microsoft-account-password)

## Sign-in did not finish or access is denied

- For an interrupted or expired sign-in, start again from a fresh login page and complete the provider flow promptly.
- If the wrong identity is selected, choose the intended account in the provider's account chooser. A separate browser profile can help keep work and personal identities distinct.
- For an organisation approval or policy message, contact your Google Workspace or Microsoft 365 administrator. An AI Easy Apps Account Admin is not automatically that organisation's identity administrator.
- If sign-in succeeds but an app is missing or access is denied, ask the app owner or account administrator to check your invitation, workspace membership and app sharing.
- Inside SharePoint, follow the login page's instruction to sign in in a new tab, then return and refresh.
- For a server configuration error, contact platform support with the error text and approximate time. Changing your password will not fix a server configuration error.

## Keep recovery information safe

Maintain recovery details and multi-factor authentication with your identity provider, following your organisation's policy. Never send passwords, verification codes, recovery codes or access tokens to an app creator or support contact. Remove sensitive information from screenshots.

If you suspect an account compromise, contact your identity administrator and platform support promptly so identity sessions and application access can both be reviewed.

## Related guides

- [Create and test your first app](/docs/getting-started)
- [Account administrator guide](/docs/account-administration)
- [Data, storage and security](/docs/data-and-security)
- [Troubleshoot a problem](/docs/troubleshooting)

---

# Account administrator guide

Set up company access, manage members and creator seats, review apps and prepare safe offboarding.

Audience: Account Owners and Account Admins (Company Admins)

Reviewed: 2026-11-05

Canonical path: /docs/account-administration

## Know which administrator you are

Account Admin, labelled Company Admin in member management, is an AI Easy Apps operational role. It is separate from Account Owner, Billing Admin, workspace roles and app roles. It does not make you a Google Workspace or Microsoft 365 administrator or allow you to reset their passwords.

The Account Owner controls owner-only actions. Available controls depend on your role, account type and subscription state. Seeing an app in company inventory does not necessarily permit opening its records.

## Start in the correct account

1. Select the company workspace you intend to manage, then open the account management page.
2. Confirm the account name and your role before changing anything. Personal and company workspaces have different ownership boundaries.
3. Use Overview for subscription and capacity. Use People, Workspaces, Apps and sharing, Billing and plan, Company activity, and Data and privacy for the corresponding tasks where available.
4. If there is no active account, select a workspace first. If access is denied, ask the Account Owner to check your role rather than creating a replacement company.

## Invite people and assign seats

Pending invitations can reserve capacity. Review unused invitations before purchasing more seats or removing an existing creator. An external app user does not need company administration rights merely to use a shared app.

1. Open People and check member and creator capacity, including pending invitations.
2. Enter the intended sign-in email. Assign the permitted role and seat type; use a creator seat only when the person needs to create apps.
3. Select workspace access where offered. Ask the Account Owner to assign privileged roles when those controls are unavailable to you.
4. Send the invitation and ask the recipient to accept using the invited Google or Microsoft identity.
5. Grant app access separately, then verify that the recipient sees only the intended apps and records.

## Review apps, sharing and connected storage

Use Apps and sharing to review company inventory and ownership or recovery controls offered for each app. Inventory access can be broader than record access. Use the supported transfer or recovery flow and resolve its blockers.

Review who owns connected Google Drive, OneDrive or SharePoint storage before changing app ownership. A platform ownership change is not proof that provider files, credentials or external sharing permissions have transferred. Check exports, forms and integrations with the intended owner after a change.

## Plan changes and billing

Use Billing and plan for the current plan, usage and permitted billing actions. Ask the Account Owner or Billing Admin to perform actions outside your authority. Account administration does not automatically include commercial authority.

Before a downgrade or trial expiry, compare assigned and pending seats with the destination plan. Review app capacity and monthly AI allowance separately. Annual payment does not turn the monthly AI allowance into a yearly pool.

## When someone leaves the company

Removing a company member is different from deleting their Google or Microsoft identity. Coordinate both processes. Do not delete external files merely to remove a person's access.

1. Review the person's owned apps, workspaces, invitations and connected storage before changing access.
2. In People, use Review removal to inspect the current company removal impact and blockers. Resolve ownership or recovery issues through supported controls or platform support.
3. The company owner confirms company-member removal. An Account Admin can help review the impact but cannot perform the owner-only confirmation.
4. Review company access after removal. Apps and records remain in the company; separately revoke Google, Microsoft and external file access with the provider or IT administrator.
5. Check integrations and business processes that depended on the departing identity. Verify the replacement owner can operate them.

## Regular administrator checks and support

- Review active members, privileged roles, pending invitations and creator seats.
- Review workspace and app sharing, including external users and record-access rules.
- Check Company activity for available management events; it is not a complete forensic record of every provider action.
- Review data handling and connected storage against your organisation's policies. Request current residency or contractual details from platform support when needed.
- For passwords or organisation sign-in policies, contact your identity administrator. For platform issues, contact support@appnastics.com with the account, affected app, error and approximate time. Never include passwords or authentication codes.

## Related guides

- [Business accounts, workspaces and creators](/docs/business-subscriptions)
- [Google and Microsoft sign-in and password recovery](/docs/sign-in-and-passwords)
- [Data, storage and security](/docs/data-and-security)
- [Allowances and product boundaries](/docs/limits)
- [Storage, snapshots and connected destinations](/docs/storage-and-sync)

---

# Product glossary

Consistent meanings for guides, discussions and AI prompts.

Audience: Everyone

Reviewed: 2026-11-05

Canonical path: /docs/glossary

## Account and workspace

Account: ownership/subscription boundary for billing, creators and shared allowances.

Workspace: collaboration context within an account, grouping apps and members; not a separate billing allowance.

## App and data

App: configured tables, views and behaviour. Table: records of one kind. Field: one attribute. Record: one stored item or row.

Key: stable record identifier. Display label: readable name, not necessarily the stored identifier.

## Views and relationships

View: presentation with layout, filtering and sorting. Record form: create/edit interface. Public form: separately published intake/questionnaire link.

Lookup: relationship to another record. Linked table: source-owned table accessed through an explicit grant.

## People

Creator: person with a seat permitting eligible creation. Internal member: account/team member. External app user: person granted selected app access rather than company administration.

App role: permissions inside an app. Account role: billing/team authority. Record access: which records can be seen or changed.

## Automation

Workflow: saved trigger, conditions and actions. AI-assisted workflow creation: drafting help, distinct from execution.

Approval request: proposed operation held for decisions before application. Snapshot/export: point-in-time copy. Synchronisation/delivery: transfer with feature-specific direction and update rules.

## Billing

App slot: capacity for a saved app, not an annual creation credit. Record allowance: active records physically owned across an app's tables. AI attempt: counted provider attempt; a request can involve several.

Annual billing: payment upfront for twelve months, with AI allowance still renewing monthly.

## Related guides

- [What AI Easy Apps does](/docs/overview)
- [Allowances and product boundaries](/docs/limits)
- [Business accounts, workspaces and creators](/docs/business-subscriptions)

---

# Roles and permissions: internal and external users

Choose who belongs to your team, who uses an external portal, and what each person can see or change.

Audience: Account administrators, app owners and people receiving access

Reviewed: 2026-11-06

Canonical path: /docs/roles

## Start with two separate choices

Internal or external describes the access relationship. The app role describes what the person may do inside a particular app. Choose both; neither an email domain nor a job title assigns permissions.

An internal team member can be a read-only Reader. An external customer can be a Contributor. External does not automatically mean read-only or limited to the person's own records: the chosen role matters.

## Internal Collaborator: part of your account

Use Internal Collaborator for someone who belongs to the account and needs to collaborate on its apps. The app-sharing flow requires the person to already be an internal account member. Add them through account member management first if necessary.

Account membership, workspace access and app sharing are separate. Being a member does not automatically grant every app or its records. An internal collaborator can use an app without becoming an administrator or app creator.

- Typical example: an employee entering jobs as a Contributor, or a trusted colleague maintaining the app as an App Editor.
- Assign a creator seat when eligible app creation is needed. A creator seat does not itself grant access to someone else's app.
- Select the app role separately in sharing. Internal roles include App Editor, Data Manager, Contributor, Approver, Reader and Global Reader.

## External Portal User: access to selected apps

Use External Portal User for a customer, supplier, partner or other person who should use a shared app without joining your workspace. An external invitation grants app-specific portal access; it does not make the recipient an account or workspace member.

External portal roles are Reader, Contributor and Approver. App Editor, Data Manager and Global Reader are not available through external sharing. External access does not grant app-building, company administration or billing authority.

- Invite the intended email and ask the recipient to open the portal invitation using that same Google or Microsoft identity.
- Review whether the invitation is pending, active or revoked. Use the available resend flow if the invitation needs replacing.
- A person may have internal membership elsewhere and external access here. Review the actual grants for this account and app instead of labelling the person permanently internal or external.

## External Approvers see their actionable records

An External Portal User with Approver access can see only records tied to a pending approval assignment they can act on now. Completing, rejecting, reassigning or revoking that assignment removes this access. A later sequential step does not grant access before its turn. An independent internal app grant retains its own permissions.

External Approvers may edit their assigned target subject to validation and approval rules, but cannot directly create or delete records. For a proposed new record, they review the approval payload without gaining access to existing records. This is not a read-only role. Use Reader for restricted reading or Contributor for customer data entry, and configure approval assignments separately.

## App roles at a glance

These are app-role capabilities, not a promise that every action is always available. Subscription state, feature availability, validation, approval processes and linked-data permissions also apply. A separate source app controls access to linked data.

- App Owner: the current owner, who may differ from the original creator after transfer. Can manage the app and sharing, and read, create, edit and delete app records. Ownership transfer and deletion use their supported checks and flows.
- App Editor: can manage app structure/settings and sharing, and read, create, edit and delete app records. This role does not itself confer owner-only transfer or app-deletion authority. Internal sharing only.
- Data Manager: can read, create, edit and delete app records and perform supported data pushes. Cannot change app structure or configure where data is sent. Internal sharing only.
- Approver: internally, can read all app records and create/edit records. Externally, can read/edit only targets of currently actionable approval assignments and cannot directly create records. Neither can delete records or manage app structure. Decisions require the relevant process assignment.
- Contributor: can create records and read/edit records they created or have an explicit record-access grant for. Cannot delete records or manage app structure. Available internally and externally.
- Global Reader: can read all app records, with no record creation, editing or deletion. Internal sharing only.
- Reader: can read records they created or have an explicit record-access grant for. Cannot create, edit or delete records. Available internally and externally.

## Account roles and creator seats are different

A company administrator may see an app in company inventory without permission to open its records. Google Workspace and Microsoft 365 administrator roles are separate again; an AI Easy Apps role does not grant control over those identity providers.

- Account Owner: account ownership and owner-only company actions.
- Account Admin (Company Admin): permitted operational administration, such as member and seat management. Some actions remain owner-only.
- Billing Admin: permitted commercial and billing tasks. Billing authority is not automatic access to business records.
- Member: uses the workspaces and apps granted to them.
- Creator seat: entitlement to eligible creation, subject to subscription and capacity. It is neither an app permission role nor blanket administration access.

## Record access is not the same as page visibility

Reader and Contributor access is restricted to records they created or that explicitly grant them access. A plain text name, a job title or a filter is not a record-access grant. Configure the supported access-grant fields and verify with the recipient's identity.

Owner, App Editor, Data Manager, internal Approver and Global Reader have broad record visibility in the app. External Approvers are restricted to currently actionable approval targets. Hiding a navigation page or filtering a view does not remove the underlying data permission. Use page visibility to organise the experience, and access rules to protect records.

## How to choose and share safely

1. Decide whether the person should join the account or only use selected apps through the external portal.
2. For an internal collaborator, confirm account membership first and assign workspace access where required. For an external portal user, use their intended sign-in email.
3. Open the app's sharing controls and choose Internal Collaborator or External Portal User.
4. Choose the least powerful Permission Role that supports the task. Use Reader for restricted reading and Contributor for restricted data entry. For Approver, distinguish internal app-wide access from external actionable-assignment access.
5. Configure any record-access grants and approval-process assignments separately.
6. Test with the recipient or a separate appropriately permissioned user. Check a record they should see and one they should not, along with creation/editing/deletion restrictions.
7. Review shared-user capacity and pending invitations. Internal app shares and non-revoked external invitations/access contribute to the app's shared-access count; creator seats are a separate allowance.

## Examples

- Employee entering service jobs: internal account member plus Contributor access to the app; a creator seat is unnecessary unless they need to create apps.
- Customer checking their own requests: External Portal User plus Reader, with explicit access to the relevant records.
- Supplier submitting updates: External Portal User plus Contributor, with access restricted to their created or granted records.
- Trusted colleague maintaining tables and workflows: Internal Collaborator plus App Editor. Review the broad record and sharing authority this gives them.
- Outside reviewer: External Portal User plus Approver and an approval-process assignment. Access is limited to records awaiting their action and ends when the assignment is no longer actionable; check that no separate internal grant gives broader access.

## Public forms and removing access

An anonymous public-form respondent is different from an External Portal User. A public submission link allows responses without sign-in; it does not grant portal membership or access to the response table.

Revoke external app access when it is no longer needed. For internal departures, use the company offboarding process and review ownership first. Check for any other grants that may still give the person access.

Removing platform access does not delete downloaded exports or revoke independent Google Drive, OneDrive or SharePoint permissions. Review those with the relevant provider as part of offboarding.

## Related guides

- [Account administrator guide](/docs/account-administration)
- [Business accounts, workspaces and creators](/docs/business-subscriptions)
- [Google and Microsoft sign-in and password recovery](/docs/sign-in-and-passwords)
- [Data, storage and security](/docs/data-and-security)
- [Request and review approval](/docs/approvals)