> ## Documentation Index
> Fetch the complete documentation index at: https://help.teable.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Cross-base access

> Read and write data across different bases in a single workflow

<Tip>
  We strongly recommend using Run script to build automations, because it can cover all action behaviors, including actions that would otherwise need to be built manually. Just describe your requirements to AI in chat.

  Please note: if you add actions manually, AI will not recognize or modify them later.
</Tip>

By default, automation actions operate on tables within the workflow's own base. Cross-Base Access lets a workflow read from and write to another base. Use it for workflows that span departments, projects, or datasets.

For example, a Sales base automation can create a fulfillment record in a separate Operations base, or a reporting workflow can pull data from multiple project bases into a single summary.

## Supported actions

| Action        | Cross-Base Support |
| ------------- | ------------------ |
| Create Record | Yes                |
| Update Record | Yes                |
| Get Records   | Yes                |

These are the three record-oriented actions. Other actions (Send Email, HTTP Request, etc.) do not need cross-base access because they do not target a specific table.

## How to set it up

1. Open a supported action (Create Record, Update Record, or Get Records) in your workflow.
2. Next to the **Table** selector, click **Cross-Base Access**.
3. A panel opens showing all spaces and bases your account can access. Select the target **Space**, then the target **Base**.
4. Choose the **Table** within that base. If the action supports it, you can also select a specific **View**.
5. Map fields and configure the action as usual. The field list now reflects the target table's fields, not the current base's fields.
6. Save the action.

## Concrete example: Sales to Fulfillment

Imagine you have two bases:

* **Sales Base** — contains a "Deals" table where the sales team tracks closed deals.
* **Operations Base** — contains a "Fulfillment" table where the ops team manages shipping.

You want to automatically create a fulfillment record when a deal closes:

1. **Trigger:** In the Sales Base, use "When record matches conditions" with filter: `Stage` equals `Closed Won`.
2. **Action:** Create Record with Cross-Base Access pointing to the Operations Base > Fulfillment table.
3. **Field mapping:** Map the deal's Customer Name, Product, Quantity, and Shipping Address to the corresponding fields in the Fulfillment table.

Now, every time a deal closes, a fulfillment record is automatically created in the Operations Base — no manual handoff needed.

## Permission model

When you create, edit, or apply workflow updates, Teable checks each cross-base action against the current editor's permissions:

| Action        | Required permission on the target base       |
| ------------- | -------------------------------------------- |
| Get Records   | Read fields and records                      |
| Create Record | Read fields and records, plus create records |
| Update Record | Read fields and records, plus update records |

Active workflow runs use Teable's automation runtime identity for the target base. Records created or updated by a cross-base action appear as **Automation Robot** in record metadata and audit surfaces.

### What happens when access changes

If the current editor does not have the required permission on the target base, Teable blocks that editor from adding or changing cross-base actions that point to that base. If a draft already contains cross-base actions the editor cannot access, Teable also blocks applying that draft. The already active version keeps running; Teable checks permissions again the next time someone edits or applies the workflow.

To fix a permission error while editing or applying a workflow:

1. Ask someone with access to both bases to edit and apply the workflow.
2. Or restore the required permissions on the target base, then apply the workflow again.

## Tips

* Cross-base access can reach bases in different **Spaces**. The editor configuring or applying the workflow must have the required target-base permissions.
* When mapping fields across bases, field types must be compatible. For example, you cannot map a text field to an attachment field.
* If you restructure a target base (rename tables, delete fields), the cross-base actions referencing those tables and fields will break. Update your workflow after making structural changes.
* For complex cross-base workflows, consider centralizing your automations in one "hub" base to keep things organized.

## Related

* [Create record](/en/basic/automation/actions/records/create-record) — create records in the current or another base
* [Update record](/en/basic/automation/actions/records/update-record) — update records in the current or another base
* [Get records](/en/basic/automation/actions/records/get-records) — retrieve records from the current or another base