Setting Up the Module Marketplace for Your Organization: An Implementation Manual

Who this manual is for

This manual is for the administrator responsible for deciding which SAVHN modules your organization actually runs, and in what order. SAVHN's Module Marketplace is where that decision gets executed: modules like CRM, HRMS, Payroll, Finance, Projects, Tickets, and the rest are enabled per organization, not bundled as an all-or-nothing package. That flexibility is useful, but it also means someone needs to think through sequencing and dependencies deliberately rather than flipping every switch on day one.

This manual assumes your organization is already created and your department structure is in place. It focuses specifically on choosing, sequencing, and validating module rollout.

Prerequisites

• Organization setup completed (see the organization setup implementation manual).
• A rough sense of which business functions you're digitizing first. Trying to launch every module simultaneously across every department is the single most common way module rollouts stall.
• Awareness of your Industry Cloud, if you selected one at setup — Industry Clouds bundle a relevant starting set of modules and configuration for that vertical, which can shortcut a lot of the decision-making below.
• A named owner for each module you plan to enable. Modules without an accountable owner tend to get configured halfway and abandoned.

Step 1: Understand how module dependencies work

Before enabling anything, understand that some modules depend on others being enabled first, because they build on records or workflows those other modules own. This isn't an arbitrary restriction — it reflects how the underlying data actually relates. A concrete example from the Education Cloud: the Fee Invoices module depends on the Enrollments module, because an invoice is generated against a specific enrollment record — you can't invoice a fee for a student who isn't enrolled in anything yet. Enable Enrollments first, and Fee Invoices can then reference real enrollment data instead of operating on nothing.

This pattern repeats across the platform wherever one module's core function is contingent on another's data existing. Before you decide your rollout order, check the dependency information the Marketplace surfaces for each module you're considering — it will tell you plainly if a module you want requires another to be enabled first.

Step 2: Inventory candidate modules against your rollout goals

List the modules you're considering, and for each one write down: which department owns it, what problem it solves for them today, and whether anything currently depends on it (per Step 1). This turns "we should probably turn on Projects at some point" into a concrete decision with an owner and a reason.

Module category	Example modules	Typical first owner
Customer-facing	CRM, Client Portal, Tickets	Sales / Support
People operations	HRMS, Payroll, Learning, Skills	HR
Delivery	Projects, Timeline, Meetings, Documents	Operations / Delivery lead
Finance	Finance, Reports	Finance
Intelligence & automation	AI Studio, AI Assistant, Automations, Manager Copilot, Business Brain, Revenue Intelligence, Journey Orchestrator, Workforce Intelligence	Cross-functional, usually enabled after core modules are stable

Step 3: Sequence the rollout — foundation modules first

Enable the modules that other modules or workflows depend on before the modules that consume them. In practice this usually means: get your core system-of-record modules for a function running cleanly (CRM for customer records, HRMS for people records, Projects for delivery records) before layering on modules that build on top of those records (Fee Invoices on Enrollments, Reports across whichever modules feed them, Automations that trigger off records in another module).

A safe general sequencing pattern:

1. Core record modules for your first target department (e.g., CRM for Sales).
2. Dependent modules that build on those records (e.g., anything that invoices, reports on, or automates against CRM data).
3. Cross-cutting modules — Documents, Chat, Meetings, Timeline — that support multiple departments at once.
4. Intelligence layer — AI Studio, AI Assistant, Manager Copilot, Business Brain, Revenue Intelligence, Journey Orchestrator, Workforce Intelligence, Automations — enabled once there's enough real data flowing through the foundation modules for these to have something meaningful to work with.

Step 4: Enable modules for one department or pilot group first

Resist enabling a new module across the entire organization on day one. Turn it on for one department or a small pilot group, let them use it for real work for a week or two, and use that period to catch configuration issues — a permission gap, a workflow that doesn't match how the team actually operates, a field that's missing — before every department hits the same problem simultaneously.

Step 5: Configure module-specific settings before opening access broadly

Once a module is enabled, it usually has its own configuration layer beyond the on/off switch — pipeline stages in CRM, department mapping in HRMS, ticket categories in Tickets, and so on. Complete this configuration with the pilot group's actual workflow in mind before widening access. A module enabled with default settings and no real configuration tends to get a lukewarm reception, not because the module is wrong for the job, but because it doesn't yet reflect how the team actually works.

Step 6: Connect role-based permissions before full rollout

Cross-reference the module against your role and permission structure (see the role-based permissions implementation manual) before opening it to the wider team. A module that's functionally ready but has nobody's permissions configured for it will either block legitimate users or, worse, expose it to people who shouldn't have access by default.

Step 7: Expand rollout and retire the pilot phase

Once the pilot group has used the module for real work without major configuration surprises, expand access to the rest of the intended audience. Keep the module's owner accountable for fielding early questions during this wider rollout — a module that works but has no visible owner tends to generate quiet frustration rather than actionable feedback.

Worked example: rolling out Enrollments and Fee Invoices together

It's worth walking through a concrete example to make the dependency model tangible. An organization running the Education Cloud wants to digitize both student enrollment and fee collection. The instinct might be to enable both modules at once and configure them together, but the correct sequence follows the dependency:

1. Enable Enrollments first, and configure it against the pilot group's real intake process — the fields that matter (program, term, student status), the workflow for a new enrollment moving from applied to confirmed.
2. Run Enrollments alone for a short period, long enough for real enrollment records to exist in the system — this is the data Fee Invoices will actually reference.
3. Enable Fee Invoices once there's real enrollment data to invoice against. Configuring Fee Invoices against an empty or sparse Enrollments module means testing it against nothing, which tells you very little about whether the configuration is right.
4. Configure Fee Invoices' own settings — fee schedules, due dates, payment tracking — against the actual enrollment records now present, and pilot it with the same group before expanding.

The same pattern holds for any dependent pair across the platform: get the foundation module generating real records first, then bring the dependent module online against that real data, rather than configuring both simultaneously in a vacuum.

Reviewing your module footprint over time

Module rollout doesn't end once your initial set is live. Revisit your enabled module list on a regular cadence — quarterly is reasonable for most organizations — and ask two questions: are there modules enabled that nobody's actually using, and are there gaps where a manual process is still running that a module could now replace, given how the rest of the rollout has matured. Organizations that treat the Marketplace as a one-time setup task rather than a living configuration tend to accumulate unused modules on one end and unaddressed manual workarounds on the other.

Coordinating Marketplace decisions with the rest of implementation

Module rollout doesn't happen in isolation from the rest of your implementation work. Every module you enable eventually needs role-based permissions configured for it (see the role-based permissions implementation manual), and if it's going to hold data migrated from an existing system, that migration needs to be sequenced against the same foundation-first order (see the data migration implementation manual). Treat the Marketplace as the anchor point for a small standing checklist each time you enable something new: who needs access, what data needs to move in, and which existing automations or reports should extend to cover it. Skipping this checklist is how a module ends up technically "enabled" for weeks while functionally unusable, because nobody can see it, no real data lives in it, and nothing else in the system is aware it exists yet.

When to involve the module's eventual owner

Bring the department or role that will actually own a module into its configuration before it goes live, not after. The person who understands how Sales actually qualifies a lead should have input into how CRM's pipeline stages are configured; the person who runs Support day to day should weigh in on how Tickets categorizes and routes incoming requests. A module configured entirely by an administrator without input from its eventual daily users tends to need a second configuration pass once real usage reveals the gap between how the admin assumed the process worked and how it actually works.

Common Pitfalls

Enabling a dependent module before its foundation module is populated with real data. Enabling Fee Invoices before Enrollments has real enrollment records means the invoicing module has nothing to invoice against — the dependency check will flag this, but it's worth understanding why rather than treating it as a blocker to work around.

Enabling every module in the catalog on day one. More modules enabled does not mean more value delivered — it means more surface area to configure, permission, and support before any of it is actually useful. Sequence deliberately.

Skipping the pilot phase for "simple" modules. Even modules that look self-explanatory usually have configuration decisions (categories, stages, templates) that benefit from one team's real usage before being locked in for everyone.

Leaving module-specific configuration at defaults. A module technically switched on but never configured to match your actual workflow tends to get abandoned quietly rather than actively rejected, which makes the problem harder to notice and fix.

Not naming an owner per module. Modules are living configuration, not one-time setup. Without a named owner, nobody notices when a module's configuration drifts out of date with how the team actually works.

Frequently Asked Questions

Can we disable a module after enabling it?

Yes. Modules can be disabled from the Marketplace if your organization decides it's no longer needed, though you should check first whether any other enabled module depends on it — disabling a foundation module that another module relies on will surface as a dependency conflict.

How do we know if a module has dependencies before enabling it?

The Module Marketplace surfaces dependency information for each module before you enable it, so you can see up front what it requires. Check this during Step 2 of your rollout planning rather than discovering it mid-rollout.

Do Industry Cloud templates change how module dependencies work?

No — Industry Clouds bundle a relevant starting set of modules and configuration defaults for a given vertical, but the underlying dependency relationships between modules (like Fee Invoices requiring Enrollments) are the same regardless of whether you arrived at a module through an Industry Cloud template or enabled it manually.

How long should a pilot phase last before expanding a module to the full organization?

There's no fixed number, but a week or two of real usage by the pilot group is usually enough to surface the configuration issues that matter — missing fields, permission gaps, workflow mismatches. If the pilot group is still finding significant issues after that window, it's worth extending the pilot rather than expanding to more users on an unstable configuration.

Getting started

Sequencing your module rollout well is the difference between a system your team adopts naturally and one that gets configured once and quietly ignored. SAVHN offers a 7-day free trial, which is enough time to enable a foundation module or two and see how the dependency model behaves with your own data. Use the pricing configurator to plan which modules you'll need and in what order, or contact the developer team directly if you want help sequencing a rollout for your specific set of departments and workflows.