Module Marketplace: Enabling & Configuring Modules

SAVHN ships as a single platform, but each organization only sees and pays for the modules it chooses to enable. The Module Marketplace is where admins turn modules on, configure their organization-specific settings, and manage dependencies between modules.

Who can manage modules

Enabling or disabling a module is an organization-level action, available to users with the Org Admin role or a custom role granted the marketplace: full_access permission. Standard users can browse the marketplace to see what's available but cannot toggle modules on their own.

Browsing the marketplace

From Admin Console → Modules (also linked from the main Marketplace navigation entry), modules are organized by category:

Category	Example modules
Core Business	CRM, HRMS, Payroll, Finance, Projects, Tickets
Collaboration	Timeline, Meetings, Chat, Documents
Customer-Facing	Client Portal, Reports
People & Growth	Learning, Skills
Automation & AI	Automations, AI Studio, AI Assistant, Manager Copilot
Intelligence	Business Brain, Revenue Intelligence, Journey Orchestrator, Workforce Intelligence
Industry Clouds	Pre-configured module bundles and workflows tailored to a specific industry

Each module's marketplace card shows a short description, its dependencies (if any), and whether it's currently enabled.

Enabling a module

1. Open the module's card in the Marketplace.
2. Review any listed dependencies — modules that must already be enabled for this one to function (see below).
3. Click Enable. Some modules present a short setup wizard on first enablement (for example, Finance asks for your default chart of accounts template; Payroll asks for your default pay cycle).
4. Once enabled, the module becomes available in navigation for any user whose role grants permission to it — enabling a module does not automatically grant every user access; role permissions still apply (see Role Management & Permissions).

Module dependencies

Some modules build on data owned by another module and therefore require it to be enabled first. Dependencies are enforced at enablement time — the Marketplace will block enabling a module until its dependencies are satisfied, and will warn before disabling a module that others depend on.

Module	Depends on	Why
Payroll	HRMS	Payroll runs off HRMS employee and compensation records
Fee Invoices / Billing workflows	Enrollments (education-oriented Industry Clouds) or Projects (services-oriented orgs)	Invoicing needs a source record to bill against
Client Portal	Projects and/or Finance (at least one)	The portal surfaces shared projects and invoices to external clients
Manager Copilot	HRMS	Team oversight features read from HRMS org-chart and attendance data
Revenue Intelligence	CRM and Finance	Combines pipeline and revenue data from both modules
Workforce Intelligence	HRMS	Aggregates workforce metrics sourced from HRMS
Journey Orchestrator	CRM	Builds customer/lead journeys on top of CRM records
Automations	— (no hard dependency), but individual automation templates may require the modules they act on	An automation that updates a Ticket needs Tickets enabled

Because dependency chains exist, disabling a foundational module like HRMS mid-lifecycle is a disruptive change — the Marketplace surfaces which dependent modules would lose functionality before you confirm.

Configuring an enabled module

Most modules expose an org-level Settings panel once enabled, reached from the module itself (its own Settings entry) or from Admin Console → Modules → [module] → Configure. Typical configuration includes:

• Custom fields and record statuses specific to your organization
• Approval workflows (e.g. who approves expense claims in Finance, or leave requests in HRMS)
• Notification rules
• Integration settings (API access, outbound webhooks — see Building Integrations with SAVHN)
• Industry Cloud-specific templates, if the module was enabled as part of an Industry Cloud bundle

Example: enabling Fee Invoices behind Enrollments

For education-sector organizations, the sequence looks like this:

1. Enable Enrollments (or the relevant Industry Cloud bundle, which enables it automatically) and configure programs/courses.
2. Return to the Marketplace and enable Fee Invoices — it will now be selectable because its dependency is satisfied.
3. Configure fee structures per program from Fee Invoices → Settings → Fee Structures.
4. Fee Invoices can now generate invoices linked to specific enrollment records, and those invoices flow into Finance and, if enabled, the Client Portal.

Sequencing a multi-module rollout

Organizations enabling several modules at once benefit from sequencing rather than enabling everything simultaneously:

1. Foundational modules first — HRMS before Payroll or Manager Copilot; CRM before Revenue Intelligence or Journey Orchestrator; Projects and/or Finance before Client Portal.
2. Configure before exposing broadly — enable a module, complete its settings (custom fields, approval chains, fee structures, and similar), and verify it with a small pilot group's role before granting it org-wide via a broadly assigned role.
3. Automations last — because Automations frequently act on other modules' records, enabling and configuring the modules an automation touches before building the automation avoids referencing fields or statuses that don't exist yet.
4. Industry Clouds as a shortcut — if your organization matches one of the 22 built Industry Clouds, enabling it applies a sensible module bundle and configuration in one step rather than sequencing each module individually; see Platform Release Notes: Module & Industry Cloud Expansion for the full list.

Module-level settings that commonly need attention post-enablement

Module	Setting worth reviewing early
Finance	Chart of accounts template, invoice numbering scheme, approval thresholds
Payroll	Pay cycle frequency, statutory deduction rules for your region
HRMS	Leave policy types and accrual rules, attendance capture method
Tickets	SLA definitions, escalation rules
CRM	Pipeline stages, lead scoring rules if used
Client Portal	Which record types (Projects, Invoices, Tickets) are exposed to external users by default

Leaving these at platform defaults is a reasonable starting point, but most organizations revisit at least the approval thresholds and SLA definitions within the first few weeks of real usage once they see how their actual workflow differs from the default assumption.

Disabling a module

1. From the Marketplace, open the module and select Disable.
2. If other enabled modules depend on it, you'll see a list of affected modules and must confirm you understand the impact before proceeding.
3. Disabling a module hides it from navigation for all users immediately. Underlying data is retained (not deleted) so the module can be safely re-enabled later without data loss, though workflows that were mid-flight when the module was disabled will need to be manually resumed after re-enabling.

Reviewing module usage over time

Once several modules are enabled and in active use, it's worth periodically reviewing actual usage rather than assuming initial enablement decisions still fit:

• Admin Console → Modules → Usage (where available) shows rough activity levels per module, useful for spotting a module that was enabled early on but never meaningfully adopted, versus one that has become central to daily work.
• A module enabled but rarely used isn't necessarily a problem — some modules (Learning, Skills) are naturally lower-frequency than others (Chat, Timeline) by design — but it's a useful signal when deciding where to invest in further configuration (custom fields, workflow templates) versus where to leave defaults alone.
• If a module was enabled for a pilot or trial and the organization has since decided against broader adoption, disabling it (after checking dependencies, as covered above) keeps the navigation focused for the rest of the organization rather than leaving unused surface area visible to every role that happens to have been granted it.

Troubleshooting

If a module you expect to see isn't appearing:

• Confirm it's enabled at the org level (Marketplace shows enabled state).
• Confirm your role has permission to it (Admin Console → Roles & Permissions, or your user-level overrides).
• Confirm any dependency it requires is also enabled.

See Troubleshooting Module & Integration Issues for a full diagnostic walkthrough.