Team Workspace

Team Workspace shares your team's DynoTable work (AI context, folders of saved views, and scanned table indexes) across everyone on the plan. All of it lives in a private S3 bucket in your own AWS account, read and written with each member's own AWS credentials. DynoTable stores your licence, never your content.

The short version

• Your data stays in your account. Shared content sits in an S3 bucket you own, reached with each member's AWS credentials. Your table names, attributes, and sample data never touch our servers.
• Three things get shared. Org-wide and per-table AI context, folders of saved table views, and table indexes one teammate scans once for everyone to import.
• Access is your own IAM. A member who can read but not write the bucket is read-only in the app. There are no extra accounts or permissions to manage inside DynoTable.
• Opt-in where it matters. Publishing a table index is off by default, and its sample values need a second opt-in before they are ever shared.

Your data stays in your AWS account

Shared content lives in a private S3 bucket in your own AWS account. Every member reads and writes it with their own AWS credentials, the same profile they already use to connect to DynamoDB. DynoTable's servers hold only your licence; your schema and sample data never leave your account.

The bucket name is derived automatically from your AWS account and Region, so there is nothing to pass around out of band: every member whose profile points at the same account and Region finds the same bucket on its own. If your team works across Regions, set the same custom bucket name on each profile instead. An admin can create the bucket in one step with hardened defaults: public access blocked, encryption on, TLS required, and versioning with superseded versions expiring after 30 days.

Because every read and write goes through your own IAM, the bucket's permissions are the boundary. There is no separate DynoTable permission layer to configure. Grant a member write access in IAM and they can publish, grant read-only and they consume.

Shared AI context

Team Workspace shares two layers of guidance with your team's AI assistant:

• Workspace context — org-wide notes every member's assistant reads: naming conventions, the access patterns you have standardised on, and gotchas specific to your data.
• Per-table context — notes attached to a single table, folded in whenever the assistant works with that table.

You edit workspace context under Settings → Knowledge and per-table context in Table Settings. Whoever has write access to the bucket authors them; every other member's assistant reads them automatically. Your own private notes stay local and need no Team plan. The shared layer sits on top of them. For what the assistant does with this context, see AI tools.

Shared folders

A shared folder is a folder of table tabs your whole team can open. Save the tabs you want to share (a filtered table view, a Smart Table, a Workbench query) into a folder and share it. Everyone on the team sees the folder and can open any tab inside it.

Shared tabs are point-in-time snapshots. Opening one loads exactly what the author saved, and a teammate's query never runs on its own: you open the tab and press Run yourself. You can edit a shared tab in place, and it is marked as modified once it differs from the shared copy. With write access you can save your version back for the team, or duplicate it to a personal copy to keep the changes to yourself.

In this version, shared folders hold table tabs only. Chat and item-editor tabs are skipped when you share a folder.

Shared table indexes

Scanning a large table to build its index (the data behind autocomplete, the indexed-field list, and the assistant's schema awareness) costs read capacity. Team Workspace lets one teammate pay for that scan once and everyone else import the result, with no re-scanning per person.

Two switches keep index sharing conservative, both off by default:

• Publishing — nothing about your indexes is shared until you turn publishing on. Once it is on, every index you build is published for the team automatically, and you can also publish one on demand.
• Sample values — with publishing on, a shared index carries field paths, types, and how often each field occurs. The actual sample values ship only if you also turn on value sharing.

Importing is always your choice. DynoTable offers an import when you have no index of your own yet, or when a teammate's is newer than yours; you decide whose scan to trust, and importing replaces your local index rather than merging counts across machines.

Set up the workspace

1. Everyone who uses the workspace needs a Team plan seat and their own AWS credentials connected, the same profile they use for DynamoDB (see Connect to AWS). Assign seats under your team members.
2. An admin creates the workspace bucket or points DynoTable at an existing one. Auto-provisioning applies the hardened defaults above.
3. Grant each member the IAM access they should have: read-only to consume, or read/write to publish. The policies are below.

Once the bucket is reachable, shared context, folders, and indexes appear in the app for every member who has a seat and whose credentials can read it.

IAM policies

DynoTable adds no permission layer of its own, so these policies are the whole access model. Swap in your own account id and Region, or your custom bucket name.

A member who consumes shared content needs read access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "FindWorkspaceBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
      "Resource": "arn:aws:s3:::dynotable-team-<account-id>-<region>"
    },
    {
      "Sid": "ReadSharedContent",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::dynotable-team-<account-id>-<region>/*"
    }
  ]
}

A member who publishes (authors context, shares folders, publishes indexes) needs one more statement on top of that:

{
  "Sid": "PublishSharedContent",
  "Effect": "Allow",
  "Action": ["s3:PutObject", "s3:DeleteObject"],
  "Resource": "arn:aws:s3:::dynotable-team-<account-id>-<region>/*"
}

The admin who creates the bucket from the app needs the bucket-level permissions once:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CreateWorkspaceBucket",
      "Effect": "Allow",
      "Action": [
        "s3:CreateBucket",
        "s3:PutBucketPublicAccessBlock",
        "s3:PutEncryptionConfiguration",
        "s3:PutBucketVersioning",
        "s3:PutLifecycleConfiguration",
        "s3:PutBucketPolicy",
        "s3:PutBucketOwnershipControls"
      ],
      "Resource": "arn:aws:s3:::dynotable-team-<account-id>-<region>"
    }
  ]
}

Read-only members and access

DynoTable shows the access your IAM actually grants rather than assuming everyone can write:

• Read-only members — a member who can read the bucket but not write it gets a read-only workspace: share, publish, and edit controls are disabled with an "ask your admin" hint. DynoTable learns this from the first write your IAM refuses, so in a new session that first attempt still reports a permission error before the controls settle.
• New permissions apply on Refresh. After your admin grants you write access, click Refresh in the Team area to pick it up.
• Losing a seat switches the workspace off, it does not wipe anything. If your Team plan lapses you can no longer open shared folders, import a team index, or have shared AI context reach the assistant. Nothing is deleted, and regaining the seat restores access.
• Missing bucket access is explained. If you cannot reach the bucket, the app tells you whether it does not exist yet or your credentials lack access, and points you to your admin.

Seats and billing

The Team plan bills per seat, and you decide who holds one.

• Everyone who uses the app holds a seat. Add and remove people under your team members. An admin manages billing and members and holds a seat; a member holds a seat and uses the app.
• Billing admins do not use a seat. Someone in finance, procurement, or IT can manage the subscription and invoices without holding a seat or app access. Name them a billing admin on your billing page.
• Your seat count follows your team. Seats track the members you have added, so adding or removing someone is what changes the bill.
• One invoice for the team. Your subscription, payment method, and invoices live on the billing page, and you can switch between monthly and annual billing there.

Next steps

Team Workspace is part of the Team plan. See pricing for what a seat includes, AI tools for what the shared context feeds, and manage your seats under your organisation.

Download DynoTable to set up a workspace for your team.