---
title: Workspace automations (your company's private catalog)
---

# Share automations with your workspace (the Workspace tab)

## What it is

### What it is

The **Workspace** tab in the Marketplace is your company's own private automation catalog. It sits
beside the public **Automations** tab and works the same way — browse, install — except nothing
here is public. These are the recipes that mention your Jira project keys, your repo paths, your
internal endpoints. They are never published to the marketplace and Omniscio staff never see them.

The tab appears once you are in a workspace. If you are not in one yet, it explains that and points
you at **Settings → Workspaces**, where workspaces are created and joined. (Workspaces are a
separate feature — this tab only holds automations; it does not create teams or manage who is in
them.)

## Where to find it

The **Workspace** tab inside the **Marketplace**, beside the public **Automations** tab. Publishing starts from any automation's **Share** dialog.

## How it behaves

### Sharing an automation with your team

Publish from any automation's **Share** dialog, the same place you publish to the public catalog —
you just pick your workspace instead. What happens next depends on how your workspace is set up:

- **Anyone can publish** — it appears in the Workspace tab immediately.
- **An admin approves first** (the default) — it waits in a review queue until a workspace owner or
  admin approves it. They see it under "Waiting for your review" at the top of the tab.

Either way the automation is packaged exactly like a public one: private things (secrets, API keys,
file paths, anything tied to your account) are stripped out first, and anything key-shaped is
flagged so you can double-check. Sharing inside your company does not lower that bar — a
colleague's machine is still a different machine.

Anything you install from the Workspace tab arrives **paused**, exactly like every other import. It
cannot run until you approve it in your inbox.

### Taking something down

The person who published it, and any workspace admin, can take a workspace automation down. It
stops appearing in the tab. Copies people already installed keep working, and your own local
automation is untouched — taking it down removes the listing, not the recipe.

### Workspace policy (what a workspace can require)

A workspace admin can set a **policy** saying what your team should have installed. Each automation
can be marked one of three ways:

- **Required** — installed automatically on everyone's machine, and kept at a specific version if
  the admin pinned one.
- **Recommended** — badged in the catalog. Nothing is installed; it is a suggestion.
- **Not allowed** — hidden from browsing, blocked from installing, and removed if someone already
  has it.

Anything with no entry is simply allowed. A workspace does not have to list every automation it
permits — only the ones it has an opinion about.

### What policy will and will not touch

**It never touches automations you wrote yourself.** Policy only acts on automations installed from
a catalog. Your own recipes are invisible to it — not by a rule that could be got wrong, but
because they carry no catalog identity for it to match against in the first place.

It also leaves a required automation alone if the admin did not pin a version. No pin means "we
don't mind which version", so it will not overwrite one you deliberately held back.

**Nothing happens silently.** Every time policy changes something on your machine you get an inbox
notice listing exactly what was installed, updated or removed, and why.

### Turning it on, and seeing what it would do

Policy has an off switch. A workspace can compose a policy and leave it un-enforced — nothing is
installed or removed while it is off. Turning it **off** later pauses it; it does not undo what it
already did.

Before enforcing anything, an admin can press **Preview changes**, which lists the exact set of
installs, updates and removals that would happen on that machine without doing any of them.
**Apply now** runs the same reconciliation for real; otherwise it happens on its own periodically.

### Publishing to the public marketplace on behalf of your workspace

A public listing can be owned by a workspace instead of one person. That matters for maintenance:
a listing owned by an individual is stranded when they change teams, while one owned by a workspace
can be maintained by any of its admins.

Transferring a listing needs you to have rights on both ends — you must be able to administer the
listing today, and be an admin of the workspace you are moving it to. The original author's byline
does not change; a transfer moves the keys, not the credit.

## For agents

### Where things live

| Thing                             | Where                            |
| --------------------------------- | -------------------------------- |
| Your workspace's automations      | Marketplace → **Workspace**      |
| The review queue (admins)         | Top of the Workspace tab         |
| Policy summary, preview, apply    | Workspace tab, under the heading |
| Creating or joining a workspace   | Settings → **Workspaces**        |
| Approving an installed automation | Your inbox                       |

## Related

- [automation-marketplace.md](automation-marketplace.md) — the public catalog this private one sits beside.
- [automations-and-auto-replies.md](automations-and-auto-replies.md) — what an automation actually is once installed.
- [my-automations.md](my-automations.md) — the list of everything you have running on a schedule.