Skip to content

Glossary

Plugin

A plugin is an add-on extending a tool you already use, built for that product's own extension system and generally working nowhere else, rather than a separate product you open on its own.

In plain terms

Something bolted onto software you already have. The word is decades old and predates any of this, which is why it gets applied loosely now: anything that adds a capability to an existing product tends to acquire the name whether or not it is one in the older sense. What distinguishes it is where it lives, which is inside somebody else's product.

01

Why it matters

It is the cheapest way for a capability to reach people, because it appears inside a tool they already open every day and needs no new account, no new habit and often no new purchase. That is also its limitation. What you build or buy for one product's extension system works in that product and is generally worthless outside it, so a strategy assembled from plugins is a strategy tied to whichever products you happen to use.

02

How it works

The host product defines what an extension may do, and that definition is the boundary. What data it can reach, what it may change, where it appears in the interface and what it is forbidden are all decided by whoever built the product, not by whoever built the add-on. That is why two plugins doing similar jobs in different products can differ so much in what they are allowed to touch.

Distribution usually runs through a directory the host controls, with some form of review before listing. The strength of that review varies enormously and is rarely described in detail, so the presence of something in an official directory is weaker evidence than it feels.

Permissions are granted at installation and are frequently broader than the task requires, for the same reason connectors are: a broad grant is easier to build against. Reading what an add-on asks for at the moment of installing it is the only convenient point at which anybody ever looks.

They are exposed to the host's decisions in a way separate products are not. An interface change, a policy change or a retired extension system can end a plugin's usefulness without warning, and the people affected have no relationship with the host to appeal to.

Where the thing lives, and what that costs you later

Where the thing lives, and what that costs you laterThe reason plugins spread so quickly is genuine: capability that appears inside a tool somebody already opens every morning gets used, and capability behind a new login often does not. Nothing on the right-hand column solves that. What the right-hand column buys is independence. Your permissions are yours rather than the host's, the arrangement outlives a change of product, and no interface decision somewhere else can quietly end it. Neither column is correct in general, and the choice is genuinely a business one rather than a technical one. It comes down to a single question that is easy to ask and rarely asked: if this product were replaced next year, would this piece of work go with it, and would that be acceptable.Inside the productAppears where people alreadywork.No new account or habit.The host decides what it maytouch.Leaves when the host does.Outside itSomewhere new to go.Its own account and access.You decide what it may touch.Survives replacing the host.Adoption favours the left columnand durability favours theright. The question worthanswering before you build ishow confident you are that youwill still be using the hostproduct in three years.
The reason plugins spread so quickly is genuine: capability that appears inside a tool somebody already opens every morning gets used, and capability behind a new login often does not. Nothing on the right-hand column solves that. What the right-hand column buys is independence. Your permissions are yours rather than the host's, the arrangement outlives a change of product, and no interface decision somewhere else can quietly end it. Neither column is correct in general, and the choice is genuinely a business one rather than a technical one. It comes down to a single question that is easy to ask and rarely asked: if this product were replaced next year, would this piece of work go with it, and would that be acceptable.
03

Seen in the wild

  • Add an assistant feature to a notes workspace and notice it appears inside pages you already had rather than as somewhere new to go.

    Notion AI
  • Read the permissions an add-on requests at the moment you install it, which is the one convenient point at which anybody looks.

    Claude
  • Compare an add-on inside one product against a standalone automation doing the same job, where the second works regardless of which product you keep.

    Zapier
04

Common misconceptions

People assume

Being in an official directory means it has been vetted.

In fact

It means it passed whatever review that host performs, which varies widely between products and is rarely described in enough detail to evaluate. Listing is a weak signal, and for anything touching confidential material it is worth knowing who built the add-on and what it does with what it sees.

People assume

A plugin and a connector are the same thing.

In fact

A plugin extends one product from inside it. A connector joins two products together from outside. The practical difference is portability: change your main tool and the plugins go with it, while a connector built between two systems survives as long as both do.

05

Telling them apart

Plugin vs Connector

Plugin

Lives inside one product's extension system, appears in its interface, and works there and nowhere else.

Connector

A link between two named systems, living outside both, and surviving a change to either end that keeps its interface.

Ask what happens if you replace the main tool. Plugins leave with it; connectors mostly do not, which is a real difference when a contract comes up for renewal.

06

Questions

Are they safe to install?
As safe as what they request and who built them. Read the permissions at installation, prefer add-ons from the host itself or from a supplier you already have a relationship with, and treat anything asking for broad access to company material as needing the same scrutiny as any other software purchase.
Should we build one or build something standalone?
A plugin if the value is being present where people already work, and standalone if the value must survive a change of tool. That is a business question about how confident you are in the host product, and it is worth asking explicitly rather than defaulting to whichever is quicker.
What happens when the host changes something?
The add-on can stop working, and you generally find out when somebody complains. Hosts vary in how much notice they give and whether they maintain older extension systems. This is the ordinary risk of building on somebody else's platform, and it is worth pricing rather than discovering.
07

Key takeaways

  • A plugin extends one product from inside it and generally works nowhere else.
  • The host decides what it may reach and change, which is why similar add-ons differ so much.
  • Directory listing means it passed that host's review, which varies and is rarely described.
  • Permissions are granted at installation and are often broader than the task needs.
  • Change the host product and the plugins go with it, which a connector mostly survives.
09

Tools that use this

  • Notion AI

    Capability appearing inside pages you already had.

  • Claude

    The permission prompt at installation, which is where to look.

  • Zapier

    Standalone automation, which survives replacing the main tool.

Last checked July 2026

All glossary terms