Skip to main content
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.
By default, automation actions operate on tables within the workflow’s own project. Cross-Project Access lets a workflow read from and write to another project. Use it for workflows that span departments, projects, or datasets. For example, a Sales project automation can create a fulfillment record in a separate Operations project, or a reporting workflow can pull data from multiple projects into a single summary.

Supported actions

These are the three record-oriented actions. Other actions (Send Email, HTTP Request, etc.) do not need cross-project 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-Project Access.
  3. A panel opens showing all spaces and projects your account can access. Select the target Space, then the target Project.
  4. Choose the Table within that project. 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 project’s fields.
  6. Save the action.

Concrete example: Sales to Fulfillment

Imagine you have two projects:
  • Sales Project — contains a “Deals” table where the sales team tracks closed deals.
  • Operations Project — 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 Project, use “When record matches conditions” with filter: Stage equals Closed Won.
  2. Action: Create Record with Cross-Project Access pointing to the Operations Project > 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 Project — no manual handoff needed.

Permission model

When you create, edit, or apply workflow updates, Teable checks each cross-project action against the current editor’s permissions: Active workflow runs use Teable’s automation runtime identity for the target project. Records created or updated by a cross-project 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 project, Teable blocks that editor from adding or changing cross-project actions that point to that project. If a draft already contains cross-project 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 projects to edit and apply the workflow.
  2. Or restore the required permissions on the target project, then apply the workflow again.

Tips

  • Cross-project access can reach projects in different Spaces. The editor configuring or applying the workflow must have the required target-project permissions.
  • When mapping fields across projects, field types must be compatible. For example, you cannot map a text field to an attachment field.
  • If you restructure a target project (rename tables, delete fields), the cross-project actions referencing those tables and fields will break. Update your workflow after making structural changes.
  • For complex cross-project workflows, consider centralizing your automations in one “hub” project to keep things organized.
  • Create record — create records in the current or another project
  • Update record — update records in the current or another project
  • Get records — retrieve records from the current or another project
Last modified on September 15, 2026