SAVHN Onboarding & Setup: Frequently Asked Questions
Getting started on SAVHN means creating an organization, choosing the modules you need, inviting your team, and configuring roles — not a lengthy implementation project with a separate consulting engagement bolted on. This FAQ covers what onboarding looks like in practice, what you need to have ready, how the organization and role structure works underneath your day-to-day use, and what to expect in the first days and weeks after you sign up.
Getting Started
How long does setup actually take?
Creating an organization and getting a first module usable — say, CRM with a few leads and a pipeline, or Tickets with a queue — takes minutes, not weeks. What takes longer is the work specific to your business: importing existing client or employee data, configuring role permissions to match your org chart, setting up integrations like a communications channel, and deciding which of the platform's optional modules you actually want enabled from day one. None of that is required before you can start using the modules you've licensed, which means you can be productive on day one and layer in configuration depth over the following days or weeks.
What do I need ready before I start?
At minimum: a company name, an admin email to register the organization, and a rough sense of which modules matter first. Everything else — team member invitations, detailed role configuration, historical data import, integration credentials — can be done incrementally after the organization exists. You don't need a completed data migration plan before you can log in and start using CRM or Tickets, and you don't need every module decided on before you begin; the Module Marketplace lets you add more later without disrupting what's already running.
How are organizations structured in SAVHN?
Every organization is a self-contained tenant. All data — clients, leads, employees, projects, tickets, documents, financial records — is scoped to that organization's ID at the data layer, so there's no shared or bleed-through data between organizations on the platform. Within an organization, you have users with roles, and those roles determine which of the organization's enabled modules a person can see and act on. This two-layer structure — organization-level module licensing, then role-level visibility within it — is consistent across every module on the platform.
Do I need IT involvement to set up SAVHN?
Basic setup — registering the organization, enabling modules, inviting team members — doesn't require specialized IT skills; it's designed to be done by whoever's driving the rollout, often an operations or admin lead rather than a dedicated technical implementer. Where IT involvement helps is around integrations (connecting a communications provider, setting up authentication policies if your organization requires it) and around larger data imports, but neither is a blocker to starting — you can begin using core modules while integration work happens in parallel.
Can I try SAVHN before committing my whole team?
Yes — the 7-day free trial exists exactly for this. You can set up a real organization workspace, enable the modules you're evaluating, and bring in a handful of team members to test the actual workflow before deciding whether to convert to a paid license and roll it out further. This lets a smaller group validate that the module fits how your team actually works before the wider rollout, rather than committing the whole organization on faith.
Roles, Access, and Structure
How do I add team members?
You invite users to your organization and assign them a role. The role determines their default access to whichever modules the organization has enabled — an admin role typically sees everything enabled, while other roles can be scoped down to just the modules relevant to their job. New team members can be added at any point after initial setup, not just during an initial onboarding window.
Can I restrict what different employees see?
Yes. Module visibility is configurable per role, separate from module licensing itself. Your organization might have Payroll and Finance enabled, but restrict visibility of those modules to Finance and HR roles rather than exposing them to every employee. If a role has no explicit restriction set, it defaults to seeing every module the organization has enabled — so scoping down access is a deliberate admin action you take as part of setting up your role structure, not something that happens automatically.
Can I bring over existing data — clients, employees, past projects?
Bringing existing records into SAVHN's modules — clients into CRM, employees into HRMS, historical projects into Projects — is part of onboarding for most organizations moving off another system or off spreadsheets. The specifics of what's supported for your data depend on the modules involved and the shape of your existing data, so this is a good topic to raise directly with the team through /book-demo if you have a non-trivial data set to bring over, particularly for larger historical data sets or unusual source formats.
What if I only need one or two modules to start?
That's the normal starting point for most organizations — you license and enable only what you need now, then use the Module Marketplace to add more later as your needs grow. There's no requirement to adopt every module at once, and no penalty for starting narrow. Many organizations start with a single module like CRM or Tickets, prove out the workflow, and expand into Projects, Finance, or an Industry Cloud once the first module is embedded in how the team works.
Do I need to configure every module before going live?
No. Each module works independently once enabled — enabling CRM doesn't require you to also configure Payroll first. You can go live with a subset of modules and layer on more configuration, and more modules, over time, at whatever pace matches your team's capacity to absorb the change.
What happens to onboarding if I'm evaluating an Industry Cloud?
Industry Clouds are pre-configured combinations of modules built around a specific profession's workflow — Construction Cloud, Healthcare Cloud, and the others each bundle relevant modules with industry-appropriate fields and structure already set up. Onboarding into an Industry Cloud starts from that pre-built configuration rather than an empty module set, which can shorten the configuration work compared to assembling the same combination from individual modules yourself and configuring every field and stage manually.
Can I change my module setup after onboarding is done?
Yes, at any time, through the Module Marketplace in your admin area. Enabling a new module makes it available to whichever roles you grant access; disabling one removes it from navigation without deleting the historical data sitting in it, so you can adjust your setup as your organization's needs change without starting over or losing what you've already built.
Is there training or documentation to help my team ramp up?
The Documentation Portal covers how the platform's core mechanics work, and each module has its own real behavior to learn hands-on inside the trial or live workspace rather than through a separate abstract training environment. Because the trial runs in a real workspace, your team's ramp-up during the trial period is genuine product familiarity, not familiarity with a stripped-down demo that behaves differently from what you'll actually use.
Can I run multiple organizations under one company, for example separate business units?
Because each organization is a fully separate tenant with its own data isolation, running multiple organizations — for distinct business units, subsidiaries, or client-facing entities — is structurally supported the same way any two unrelated customers on the platform are separated. If this fits your situation, it's worth discussing the specifics with the team through /book-demo, since the right structure depends on how much your business units actually need to share versus keep separate.
Who do I talk to if my onboarding needs are unusual?
If your situation involves a large data migration, an uncommon module combination, or specific compliance requirements, /book-demo connects you with a real person on the team who can talk through the specifics rather than leaving you to guess from generic documentation.
What's a realistic timeline for a mid-sized organization to be fully rolled out, not just set up?
Getting the organization created and a first module usable is fast, as covered above, but "fully rolled out" — every relevant team member onboarded, roles configured to match your structure, historical data imported, and the team comfortable with day-to-day workflows — realistically takes longer and depends heavily on how much historical data you're bringing over and how many modules you're adopting at once. Organizations that start narrow (one or two modules) and expand tend to reach comfortable, confident usage faster than those that try to configure everything simultaneously on day one.
Does SAVHN assign someone to help with my onboarding, or is it entirely self-serve?
Basic self-serve onboarding — registering, enabling modules, inviting users — doesn't require a dedicated point of contact. For onboarding involving a non-trivial data migration, an Industry Cloud evaluation, or a larger seat count, /book-demo is the path to a real conversation with the team, rather than assuming either a fully hands-off or fully white-glove experience applies universally regardless of your situation.
What if my team is used to a different tool and is hesitant to switch?
This is a change-management question as much as a technical one, and it's usually easier to manage by starting with the one or two modules that solve the most immediate pain point rather than migrating every workflow simultaneously. Because modules work independently, you can prove out value in, say, Tickets or CRM before asking the team to also adopt Finance or HRMS, which tends to reduce resistance compared to a single big-bang rollout.
Is there a way to test configuration changes without affecting my live team's work?
Because the 7-day free trial runs in a real, separate organization workspace, you can use a trial organization to test out configuration approaches — role structures, module combinations — before applying the same setup to your actual live organization, if you want to validate an approach before committing your team to it directly.
Can I set up SAVHN for a department first and expand company-wide later?
Yes — because organizations, roles, and modules are all configurable independently, a common pattern is starting with one department or team, proving the workflow fits, and then inviting additional teams and enabling additional modules as confidence grows. There's no structural requirement to onboard the entire company in one pass, and starting narrow often surfaces configuration questions (like the right role structure) more cheaply than a full rollout would.
What's the difference between an admin role and a regular user during onboarding?
An admin role is typically the one that registers the organization, enables modules through the Marketplace, invites other users, and configures role-based module visibility — the setup and configuration actions described throughout this FAQ. Regular users are invited into whatever role an admin assigns them and see whatever modules that role has visibility into; they don't need to touch the Marketplace or role configuration themselves to start working day to day.
Does onboarding differ meaningfully between a small team and a large enterprise deployment?
The underlying mechanics — organization creation, module enablement, role configuration — are the same regardless of size, but a larger deployment naturally involves more of the work that scales with team size: more roles to define, larger data imports, more integration connections to configure. This is exactly the kind of situation where a direct conversation through /book-demo, rather than a purely self-serve rollout, tends to be worth the time for both sides.
Ready to see how fast setup actually is? Start with SAVHN's 7-day free trial — no card required — and configure the exact module combination your organization needs through the Visual Pricing Configurator. If your onboarding has specifics that don't fit a generic answer, reach out through /book-demo or contact the developer team directly.