This guide is for SaaS partner operators, white-label program owners, and partner-admin users who need a practical walkthrough of partner tenancy, setup, branding, launch readiness, and the hosted customer journey without confusing that work with broker or importer portal roles.
Main workspace /partners/setup5 screenshot-backed walkthroughs
At a glance
Use the partner-admin workspace to configure the hosted tenant, prepare branding and launch data, and understand the customer-safe hosted flow the SaaS partner is operating.
Start from the partner-ops model, not from a borrowed broker workspace
SaaS partners now have a real white-label operating track. The partner relationship still starts as a `saas_partner` tenant type, but the human setup work runs through partner operations and the `partner_admin` workspace rather than the broker portal.
/admin/integrations/partners/partners/setup
Use Partner Operations to understand whether the organization is already modeled as a SaaS partner, what capabilities it has, and whether the tenant is still dark, sandbox-ready, approved, or live.
Open the dedicated partner setup workspace instead of trying to repurpose broker registration, broker invites, or importer onboarding as the partner-admin console.
Treat the partner org, white-label tenant, and hosted launch state as separate truths: the org owns tenancy and credentials, the tenant owns host-facing identity, and launch state controls whether the hosted experience is actually live.
A SaaS partner is still an API tenant type, not the same thing as a broker persona.
The operational human role is `partner_admin`, and its main-host home path is /partners/setup.
Partner Operations is the control plane where DutyClaims distinguishes SaaS partner tenancy, capability state, and white-label readiness from importer or broker portal users.
Configure branding, disclosures, support, and credentials before asking for launch
The SaaS partner setup motion is about hosted identity and operational truth, not delegated financing control. Branding, support routing, disclosures, API credentials, and webhook readiness all belong in the same white-label preparation track.
Use the partner setup workspace to reserve the hosted tenant identity, complete the onboarding packet, and save the support or disclosure data that the hosted runtime will later surface.
Configure partner branding with the expectation that hosted visuals and partner-attributed messaging can change while DutyClaims still remains the financing provider behind the flow.
Create managed credentials, OAuth clients, and webhook endpoints from the same setup lifecycle so launch readiness reflects the canonical partner record instead of disconnected setup notes.
Setup is resumable and reviewable; it is not a one-shot launch wizard.
Branding truth and sender-domain truth remain separate.
Branding settings capture hosted identity, reply routing, CTA labels, and disclosure posture without implying that the partner owns financing or unrestricted outbound delivery.
Move from setup to explicit review and launch gates instead of assuming the host is live
White-label launch is deliberately gated. Saving branding or reserving a slug does not mean the hosted tenant is public; review, domain readiness, and launch state remain explicit.
Use the launch center to track default-host readiness, optional custom-domain requests, and the exact blockers that still separate sandbox-ready from production-live.
Expect DutyClaims operators to review the white-label packet and the final launch gates before a tenant moves from approved to live.
Use the domain and launch surfaces to understand failover, suspension, and dark-launch state instead of inferring live status from a reserved subdomain alone.
Hosted launch is admin-controlled in v1.
Default-host readiness, custom-domain readiness, and sender-domain readiness are different states.
No captured screenshot is wired into this section yet. The walkthrough still reflects the real route and UI labels in the current codebase.
Know the customer journey your hosted tenant is operating
A SaaS partner is also responsible for understanding what its customers will see on the hosted tenant. The partner brand owns the relationship layer, while the customer journey still reuses DutyClaims onboarding, dashboard, and claim pages underneath.
Expect invited or direct customers to enter through hosted auth and join flows that preserve partner attribution and redirect onto the supported customer-safe route set.
Hosted onboarding still moves through company registration, import profile, and eligibility so DutyClaims can scope the centralized financing workflow correctly.
After activation, customers land in the slim hosted dashboard and claim pages rather than in admin, CRM, attorney, or broker-ops surfaces.
The hosted tenant is a branded customer shell, not a separate lender stack.
Only the supported customer-safe pages stay on the tenant host in v1.
Customers enter through the same auth shell shape the hosted tenant uses for sign-in and sign-up, with partner attribution preserved before onboarding begins.Hosted customer onboarding still starts with company registration because the white-label layer changes presentation, not the underlying DutyClaims importer setup contract.After onboarding, the hosted tenant keeps customers on the supported dashboard and claim routes while DutyClaims-owned financing and operator workflows stay on the main host.