Workspace automations (your company's private catalog)

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 — the public catalog this private one sits beside.
• automations-and-auto-replies.md — what an automation actually is once installed.
• my-automations.md — the list of everything you have running on a schedule.