This guide is for operators who own daily platform health, case management, diligence analyst work, seller data-room workflows, partner operations, provider readiness, and customer-facing release communication inside DutyClaims.
Main workspace /admin/analytics30 screenshot-backed walkthroughs
At a glance
Use the admin and internal-ops workspaces to run approvals, work the claims pipeline, manage diligence and seller data rooms, inspect partner readiness, debug delivery health, and publish updates.
Use Analytics and Integration Readiness as the operator control plane
Admin starts with system-wide posture. Analytics answers what is happening across the business, while Integration Readiness answers whether provider-backed flows are actually safe to run.
/admin/analytics/admin/integrations
Start with Analytics when the question is pipeline volume, trend, or aggregate operating posture.
Open Integration Readiness when the question is deployment-health, provider configuration, or whether a live automation can safely fire.
Treat these pages as operational truth, not as one-off configuration forms.
Analytics is the business lens.
Integration Readiness is the deployment-health lens.
Analytics is the management lens. Use it when the question is volume, trend, or system-wide posture.Integration Readiness tells operators which provider-backed workflows are actually configured and safe to run live.
Review broker and attorney admissions from dedicated approval queues
Human admissions are not blended into generic CRM work. Broker applications, broker credentials, and attorney onboarding each have their own operator surface.
Use Broker Approvals to review new brokerage applications and manage decision state.
Inspect the broker API key page when troubleshooting a live integration or readiness question for one approved broker.
Use the Attorney Review Queue to review onboarding packets, credential evidence, and follow-up needs without mixing them into broker operations.
Broker admission and attorney admission are separate operator motions.
Broker API keys answer how an approved broker authenticates machine traffic; they do not replace the approval workflow.
Broker Approvals is the intake and review surface for brokerage admission.Broker API keys stay visible to admins so integration debugging does not require database spelunking.The attorney queue is the operator surface for identity and credential review before the attorney workspace becomes fully active.
Work the claims pipeline from CRM and claim review pages
CRM is the daily case-operations queue for admins and case managers. It handles ownership, claim stage, offer activity, and one-record operator action.
/crm/crm/claims/[id]
Use CRM filters, stage views, and saved views to manage open claim pipeline across owners and statuses.
Open claim review when you need to send offers, inspect claim state, override eligibility, or jump directly to supporting documents.
Treat CRM as the day-to-day case-operations queue, not as a passive reporting surface.
CRM answers what is moving now.
Claim review pages are where operator action becomes record-level.
CRM is the operator queue for claim ownership, stage posture, and next-action discipline across the live pipeline.Claim review is the record-level operator workspace for offers, overrides, and direct claim inspection.
Use Diligence dashboard, manual review, and analytics for portfolio triage
Case managers and diligence admins have a second operating track beyond CRM. The diligence surfaces make seller-document status, analyst work, and portfolio posture explicit.
Start on the Diligence dashboard for bulk job progress, document blockers, and the next analyst tasks.
Use Manual review queue for RF8 evidence capture, document exceptions, and other deliberate analyst work that cannot be automated away.
Use Portfolio analytics when leadership needs throughput and portfolio-level diligence posture rather than one queue.
Dashboard is the control surface.
Manual review is the analyst workbench.
Analytics is the management layer.
Operator guides own RF8 evidence workflow; partner API docs only expose the resulting rf8Review contract state.
The Diligence dashboard is the control surface for portfolio state, document blockers, and analyst next actions.Manual review is the analyst workbench for deliberate evidence capture and document-exception handling.Portfolio analytics moves the view from one queue item to system-wide diligence posture.
Create portfolios and run post-close work from the portfolio surfaces
The diligence portfolio stack separates portfolio creation, overview, uploads, refunds, IRR, protest readiness, and batch ingestion into explicit surfaces.
Use Portfolios to create or select a seller portfolio and branch into upload or overview work.
Use the portfolio overview page for status, completeness, valuation, and recent bulk-job context.
Use Upload for document ingestion, Refunds for post-close receipt reconciliation, IRR for economics, and Protests for readiness posture.
Use Bulk Upload when onboarding multiple portfolio files or large intake batches.
Portfolio pages separate intake, valuation, refund reconciliation, and protest readiness on purpose.
Treat the overview page as the portfolio spine and the subpages as explicit work tracks.
Portfolios is the creation and routing surface for seller packages entering the diligence workflow.Portfolio overview is the spine of the diligence portfolio workspace, tying state, completeness, valuation, and recent activity together.Upload is the document-ingestion surface for one portfolio once the shell record already exists.Refunds is the post-close reconciliation page for expected versus received refund activity.IRR is the economics layer for portfolio review once refund and cost posture need to be modeled explicitly.Protests keeps legal-readiness posture visible at the portfolio level instead of hiding it inside miscellaneous analyst notes.Bulk Upload is the batch-ingestion surface for larger diligence intake jobs.
Use Data Rooms for seller completeness checks and rejection handling
Data room status is separate from portfolio economics. The data room routes keep seller-document completeness and rejection posture visible as their own workflow.
Open the data room dashboard to see which portfolios are incomplete, under review, or rejected.
Use the portfolio-level data room page as the checklist and completeness workspace for one seller package.
Use the rejection page when remediation needs to be made explicit for the seller or internal follow-up.
Data room status is separate from portfolio economics.
Rejection state should stay visible instead of being buried in email.
The data room dashboard shows which portfolios need completeness work before diligence can safely proceed.The portfolio data room page is the checklist workspace for one seller package.Rejection pages make remediation explicit instead of forcing operators to reconstruct missing items from scattered notes.
Manage tariff schedule truth from the HTS registry console
HTS schedule management sits in its own admin console because tariff-source quality affects search, eligibility, and downstream claims behavior.
/admin/hts
Use HTS Schedule to manage tariff rows, source state, audit history, and official-release sync posture.
Check registry mode and runtime-source context before assuming an eligibility issue is caused by the claim layer.
Use this surface when the question is tariff data quality or release freshness.
The HTS console is the tariff truth layer for search and eligibility.
It is operational data management, not just a lookup page.
HTS Schedule is the tariff-truth console for registry rows, sync posture, and audit history.
Run external partner operations from Integrations and Partner Operations
Partner Operations is for external API tenants such as brokers and SaaS partners. It is not the place to manage importer or attorney portal users.
Create or inspect partner organizations from Partner Operations rather than treating external API tenants as portal roles.
Use White-Label Fleet Ops for cross-tenant health, alert posture, outbound-email pause state, and the current launch-support queue before drilling into one tenant.
Use Scan audit, Counterparty diligence, Financing, and Branding subpages when the question is partner-specific capability posture or downstream provider behavior.
Open the tenant white-label ops detail page when the issue is attached host health, hosted auth or dashboard posture, launch blockers, or operator kill-switch state for one tenant.
Keep partner activation separate from deployment readiness; /admin/integrations answers platform readiness, /admin/integrations/white-label answers the fleet, and partner pages answer one tenant's lifecycle.
Partner orgs are external API tenants.
They are not Clerk personas.
Fleet Ops is the day-two support surface for hosted white-label tenants.
White-Label Fleet Ops is the cross-tenant operator surface for hosted health, alerts, and outbound-delivery posture before support drills into one tenant.Partner Operations is the tenancy and lifecycle surface for external broker and API partners.Scan Audit is the operator view into partner portfolio scan status, failures, and throughput behavior.Counterparty diligence keeps manual and provider-blocked underwriting posture visible without exposing analyst-only internals.Financing readiness is the operator view into one partner's financing-specific lifecycle and blockers.Tenant white-label ops is the one-partner support workspace for launch blockers, host health history, alerts, and operator kill switches.Branding controls keep partner-specific presentation rules separate from the rest of the partner tenancy record.
Use Email Console when delivery, retries, or suppressions are in question
The email surface is for delivery debugging, suppressions, retries, and automation pause state. It is the right place to go when the system may have sent a message but the user is unsure.
/admin/email
Use filters to narrow the exact queue slice you care about.
Inspect delivery state before concluding that a provider outage or code bug occurred.
Use the console for retries, suppression review, and automation pause context.
Email Console is operational, not marketing-only.
It exists to remove guesswork from outbound delivery debugging.
Email Console is where operators verify what was sent, what failed, and what is paused or suppressed.
Publish roadmap and release communication from Product Updates
Product Updates is the admin-facing publishing surface for customer-visible change notes and roadmap communication.
/admin/product-updates
Use Product Updates to review changelog or roadmap drafts.
Publish from the admin surface rather than editing storage directly.
Treat it as the operator bridge between internal shipping state and external product communication.
This page is about product communication, not runtime system health.
Product Updates is the publishing workflow for external change communication.