Catalog

The catalog lists the apps in your organization. It answers “has someone already built this?”, a question people only ask when there’s somewhere to ask it.

What appears in it

Apps their owners have published. Publishing makes an app findable; it doesn’t change who can open it. A published Specific users app is listed for the whole organization even though only its list can open it: everyone else sees that it exists and can request access from the owner.

Guests don’t see the catalog at all.

Publishing

An app’s owner publishes it from the Catalog section of the app’s settings, and can unpublish it there at any time. New apps are unpublished unless Publish to the catalog is ticked in the add dialog, or sbd register is given --publish.

An organization can require approval instead. With Require an admin to approve each app before it is listed turned on in Org settings → Catalog, publishing becomes Request publish, with an optional message to the admins. The app stays out of the catalog until an admin answers:

• Admins are notified, and approve or deny from Org settings → Catalog, the notification, or the email.
• The owner is told either way. A denied app can be requested again.
• The owner can withdraw a request that hasn’t been answered.
• Admins follow the same rule for their own apps, and can approve their own requests.

Turning the setting off publishes every app still waiting. Turning it on leaves apps already in the catalog where they are.

Deleting a published app removes it from the catalog; the delete confirmation says so.

Finding things

Entries carry a name, description, owner, and tags, and can be searched and filtered by tag or owner. Tags are shared across the organization, so a tag someone else added is one you can filter by.

On a personal or group page, the filter can also narrow apps to published ones.

Writing an entry worth finding

The description is the entry. Say what the tool does and who it’s for: “Weekly pipeline numbers by region, refreshed each Monday, built for EMEA sales” works; “Sales dash v2” doesn’t. Lead with the problem, since people search for their problem rather than your tool’s name. Say where the data comes from and how fresh it is, which is the first thing anyone asks. Skip the implementation.

Tag consistently. Two spellings of the same idea split a filter in half.

Keeping it honest

A few stale entries teach people not to trust any of them. Keep ownership current, and prefer group ownership for anything a team depends on, so a tool doesn’t quietly become unmaintained when its author moves on. Unpublish what nobody should be finding any more.

Search before you build. Ten seconds occasionally saves a week.