Migrate your Request Manager data
Internal request-and-approval workflow system for enterprise teams that need to route, track, and audit inbound requests across departments — not a general-purpose helpdesk.
In its favor
Why people choose Request Manager
The signal that keeps Request Manager on the shortlist. Sourced from G2, Capterra, and customer scoping calls.
Centralizes all inbound requests into a single application rather than managing emails or spreadsheets across teams — one reviewer noted it 'centralised all requests to the firm' and improved internal communication.
Provides a structured approval workflow with escalation steps, allowing managers to monitor request progress and receive notifications on status changes.
Serves enterprise organizations (1000+ employees) with the capacity to route and track high volumes of internal requests across multiple departments.
Offers a structured request and approval process that enforces consistency, reducing ad-hoc approvals and improving auditability of organizational decisions.
Scales to handle construction and similar industries with large teams, as evidenced by a verified enterprise reviewer in the construction sector.
Poor reporting and analytics capabilities — one verified G2 reviewer explicitly flagged 'Poor Reporting' as a frustration, limiting visibility into request trends and team performance.
Limited customization of workflow states and approval chains, making it difficult to model complex organizational structures with multi-step or conditional approvals.
User interface and usability issues for non-admin users, with reviewers noting the platform is functional but not intuitive for requesters unfamiliar with the approval process.
Absence of native integrations with common enterprise tools like Slack, Microsoft Teams, or project management platforms, requiring workarounds for notification and sync.
Lack of a public API documented in available resources, making automated integrations and data exports dependent on vendor-provided tooling.
Reasons to switch
Why people leave Request Manager
The recurring reasons buyers give for replacing Request Manager. Presented as facts, not knocks.
Platform scorecard
Strengths, weaknesses, and where Request Manager fits
Grades across six dimensions, plus a SWOT-style view of where the platform shines and where it falls short.
SWOT — strengths, weaknesses, and use-case fit
Strengths
Weaknesses
Where it works
Where it struggles
Pricing tiers
Request Manager pricing overview
HealthMark Group Request Manager (a HIPAA-compliant medical-records release-of-information request portal) does not publish pricing publicly. The product is sold as part of HealthMark Group's broader Release of Information (ROI) services to physician practices and healthcare providers, with pricing typically based on request volume, organization size, and service tier. HealthMark advertises 85% of requests delivered in 8 hours or less, with standard requests taking 2-3 business days. Customers should contact HealthMark Group directly via healthmark-group.com for a quote.
Custom (Sales-Led)
Tier 1 of 1
Custom (Sales-Led)
What's included
Need help selecting your Helpdesk?
Book a free 30 minute consultationPricing is informational. FlitStack AI does not bill on Request Manager's schedule — see our quote-based pricing →
What gets migrated
Request Manager object support
Object-by-object support for Request Manager migrations. Per-pair details surface during scoping.
Tickets
Fully supportedTickets are the core object in Request Manager. We migrate Ticket records 1:1 including all standard fields: subject, description, priority, status, created/updated timestamps, and requester reference. Custom fields are mapped individually per customer.
Requesters
Fully supportedRequester records represent the submitting users. We preserve the full user profile including name, email, department, and contact details. Where the destination uses a Contact or User object, we map accordingly.
Approvers
Mapping requiredApproval chain records link approvers to tickets with step-order, approval status, and timestamp. We preserve the chain structure but map to the target's approval workflow model — which varies significantly between platforms.
Attachments
Mapping requiredFile attachments on tickets are extracted with their filename, MIME type, and content. Upload to the destination is handled via the target's attachment API or file storage mechanism. Large-file handling is chunked where the target API requires it.
Comments
Mapping requiredTicket comments and internal notes are treated as Conversations or Activity records. Author, timestamp, and body are preserved. Private vs. public flag is mapped to the destination's equivalent visibility setting.
Custom Fields
Mapping requiredOrganizations frequently add custom fields to ticket objects. These require per-customer field mapping: we extract the custom field schema during scoping and map each to a target field or store as a custom property.
Priority Levels
Fully supportedPriority values (e.g., Low, Medium, High, Critical) are preserved as categorical fields. We do not re-normalize priority scales unless explicitly requested.
Status Workflows
Mapping requiredRequest Manager status values (e.g., Draft, Submitted, Under Review, Approved, Closed) are mapped to the destination's workflow states. Exact state mapping is confirmed during scoping.
Departments
Mapping requiredDepartment assignments on tickets or requester profiles are mapped to the destination's org/unit object. Self-hosted or on-premise deployments may require manual department recreation.
| Object | Support | Notes |
|---|---|---|
| Tickets | Fully supported | Tickets are the core object in Request Manager. We migrate Ticket records 1:1 including all standard fields: subject, description, priority, status, created/updated timestamps, and requester reference. Custom fields are mapped individually per customer. |
| Requesters | Fully supported | Requester records represent the submitting users. We preserve the full user profile including name, email, department, and contact details. Where the destination uses a Contact or User object, we map accordingly. |
| Approvers | Mapping required | Approval chain records link approvers to tickets with step-order, approval status, and timestamp. We preserve the chain structure but map to the target's approval workflow model — which varies significantly between platforms. |
| Attachments | Mapping required | File attachments on tickets are extracted with their filename, MIME type, and content. Upload to the destination is handled via the target's attachment API or file storage mechanism. Large-file handling is chunked where the target API requires it. |
| Comments | Mapping required | Ticket comments and internal notes are treated as Conversations or Activity records. Author, timestamp, and body are preserved. Private vs. public flag is mapped to the destination's equivalent visibility setting. |
| Custom Fields | Mapping required | Organizations frequently add custom fields to ticket objects. These require per-customer field mapping: we extract the custom field schema during scoping and map each to a target field or store as a custom property. |
| Priority Levels | Fully supported | Priority values (e.g., Low, Medium, High, Critical) are preserved as categorical fields. We do not re-normalize priority scales unless explicitly requested. |
| Status Workflows | Mapping required | Request Manager status values (e.g., Draft, Submitted, Under Review, Approved, Closed) are mapped to the destination's workflow states. Exact state mapping is confirmed during scoping. |
| Departments | Mapping required | Department assignments on tickets or requester profiles are mapped to the destination's org/unit object. Self-hosted or on-premise deployments may require manual department recreation. |
Gotchas
What to watch for in Request Manager migrations
Issues we've hit on past Request Manager migrations, tagged by severity. FlitStack AI handles every one — surfacing them up front because buyer engineering teams want to know.
No documented public API for automated export
Reporting limitations obscure historical volume data
Custom fields vary by organization
| Severity | Issue |
|---|---|
| High | No documented public API for automated export |
| Medium | Reporting limitations obscure historical volume data |
| Medium | Custom fields vary by organization |
Leaving Request Manager?
Where Request Manager customers move next
7 destinations Request Manager can migrate to.
How a Request Manager migration works
Four steps, Request Manager-specific
Connect
Email-based verification (passwordless) for patient request portal; backend integrations not publicly documented into Request Manager. Scopes limited to read-only on the data we move.
Map
We translate Request Manager-specific structures (custom fields, objects, value lists) to the destination's model.
Sample
Test with a 50–200 record subset to validate Request Manager quirks before production.
Migrate
Full migration with Request Manager rate-limit handling. Rollback available throughout.
FAQ
Request Manager migration FAQ
Answers to the questions buyers ask most during Request Manager migration scoping. Not seeing yours? Book a call.
Can't find your answer?
Walk through your Request Manager migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationOther helpdesks we support
Ready when you are
Migrate Request Manager.
Without the rebuild.
Free scoping call with a migration engineer. Tell us about your Request Manager setup and destination — written quote back within a business day.