Skip to content
Kisum • Documentation

Backend Core Addons

Related documentation: Backend Core Packages · Backend Core Modules · Commercial Model · Permissions Blueprint · Permissions Catalog

Add-on Catalog Design Specification

Section titled “Add-on Catalog Design Specification”

An add-on is an optional commercial extension.

It answers:

What extra capability can a company buy on top of what it already owns?

Add-ons are optional and must always be explicitly compatible with a package or standalone-module purchase model.

1. Current add-on catalog from the platform definition

Section titled “1. Current add-on catalog from the platform definition”

The attached commercial definition currently includes these add-ons:

  • Vendor directory
  • Venue directory
  • Live ticket sales in your events
  • AI report over sales for marketing campaigns

2. What an add-on is for

Section titled “2. What an add-on is for”

An add-on exists when the platform wants to sell an optional capability without redefining the package or creating a full standalone module.

An add-on is appropriate when:

  • the capability is optional
  • the capability enhances an existing product path
  • the capability has clear commercial value
  • the capability does not need to become its own primary module

An add-on is not appropriate when:

  • the feature is the main reason a customer buys the product
  • the feature has a full product identity on its own
  • the feature needs its own complete entitlement model independent of other products

3. Add-on definitions

Section titled “3. Add-on definitions”

3.1 Vendor directory

Section titled “3.1 Vendor directory”

Purpose

Section titled “Purpose”
  • unlock access to vendor-directory capability

Commercial meaning

Section titled “Commercial meaning”
  • optional enhancement
  • not itself a base package
  • supports discovery and operational workflows around vendors

Typical permission impact

Section titled “Typical permission impact”
  • basic.vendors.read
  • basic.vendors.search

3.2 Venue directory

Section titled “3.2 Venue directory”

Purpose

Section titled “Purpose”
  • unlock access to the venue-directory capability

Commercial meaning

Section titled “Commercial meaning”
  • optional enhancement
  • distinct from the standalone venue management module
  • supports venue discovery and venue metadata usage

Typical permission impact

Section titled “Typical permission impact”
  • basic.venues.read
  • basic.venues.search

3.3 Live ticket sales in your events

Section titled “3.3 Live ticket sales in your events”

Purpose

Section titled “Purpose”
  • unlock live ticket-sales functionality for company events

Commercial meaning

Section titled “Commercial meaning”
  • event and reporting enhancement
  • may expand what “actual” reporting means in the Basic package
  • may be a dependency for downstream reporting and AI analysis

Typical permission impact

Section titled “Typical permission impact”
  • finance.ticketing.read
  • finance.ticketing.write
  • basic.events.ticketing-manage

3.4 AI report over sales for marketing campaigns

Section titled “3.4 AI report over sales for marketing campaigns”

Purpose

Section titled “Purpose”
  • unlock AI-driven sales reporting for marketing campaigns

Commercial meaning

Section titled “Commercial meaning”
  • optional intelligence layer
  • should be compatible only where the underlying sales or ticketing context exists
  • should not exist as a disconnected AI capability with no source data

Typical permission impact

Section titled “Typical permission impact”
  • ai.sales-reports.read
  • ai.marketing-insights.read

4. How add-ons should work

Section titled “4. How add-ons should work”

Every add-on must define:

  • stable key
  • human-readable name
  • description
  • active status
  • compatible packages
  • compatible standalone modules
  • whether it unlocks a full module or only a capability slice
  • whether it requires another capability to function meaningfully

4.1 Add-ons must not be ambiguous

Section titled “4.1 Add-ons must not be ambiguous”

An add-on must clearly be one of:

  • a capability enhancer
  • a data-source enhancer
  • a reporting enhancer
  • a workflow enhancer
  • a module unlocker

It should never be documented vaguely as “something extra” without a clear product boundary.

4.2 Add-ons must define compatibility

Section titled “4.2 Add-ons must define compatibility”

For every add-on, document:

  • requires Basic: yes or no
  • can be combined with standalone module purchases: yes or no
  • conflicts with any other add-on: yes or no
  • becomes redundant if another package or module is purchased: yes or no

4.3 Add-ons must define dependency rules

Section titled “4.3 Add-ons must define dependency rules”

Some add-ons may depend on another capability.

Example:

AI sales report add-on
-> should require access to meaningful sales or ticketing data

That dependency must be explicit in the catalog.

5. How to add new add-ons in the future

Section titled “5. How to add new add-ons in the future”

Create an add-on when:

  • the capability is optional
  • it should not become a full standalone module
  • it has clear commercial value
  • it can be attached to an existing package or module cleanly
  • it has a narrow and understandable product meaning

Do not create an add-on when:

  • the feature is actually a full module
  • the feature should always be included in the base package
  • the feature exists only because of pricing convenience
  • the feature would require its own large permission tree and lifecycle

5.1 Future add-on checklist

Section titled “5.1 Future add-on checklist”

Before adding an add-on, define:

  • add-on key
  • business purpose
  • allowed packages
  • allowed standalone modules
  • dependency rules
  • conflict rules
  • permission-family impact
  • whether the add-on is operational, reporting, data, or intelligence oriented

6. Add-ons versus modules

Section titled “6. Add-ons versus modules”

6.1 Module

Section titled “6.1 Module”

A module is a product boundary.

6.2 Add-on

Section titled “6.2 Add-on”

An add-on is a commercial extension.

6.3 Design rule

Section titled “6.3 Design rule”

If the capability can meaningfully be sold and operated as a full standalone product, prefer a module.
If it only enhances an existing product path, prefer an add-on.

7. Relationship to permissions

Section titled “7. Relationship to permissions”

Add-ons do not directly grant user permissions.

Instead:

  • add-on purchase enables capability eligibility at company level
  • Auth then determines whether the user actually receives access

Example:

Company bought live-ticket-sales add-on
-> company becomes eligible for ticketing-related capability
-> user still needs the appropriate module and permission grants

7.1 Add-on permissions should stay consistent with module namespaces

Section titled “7.1 Add-on permissions should stay consistent with module namespaces”

Where possible, permissions enabled by an add-on should still use the module namespace that owns the capability.

Example:

  • finance.ticketing.read
  • not live-ticket-sales.read

This keeps permission design stable and reduces catalog drift.

8. Relationship to delegation

Section titled “8. Relationship to delegation”

Add-ons affect delegation indirectly.

If an add-on makes a permission family commercially possible, delegation may then decide whether a user is allowed to grant that access to other users.

Example:

Company bought Venue Directory add-on
-> company may become eligible for venue-directory related permissions
-> manager may still be forbidden from granting those permissions to others

So:

  • add-on = commercial eligibility
  • permission = user action
  • delegation = grantability to other users

9. Summary

Section titled “9. Summary”

Add-ons are optional commercial enhancements.

They must be:

  • clearly defined
  • commercially meaningful
  • explicitly compatible
  • separated from full module design
  • cleanly mapped to permission eligibility, not direct user grants