Capture every record, wherever it lives.
M365, ServiceNow, FOIA.gov, file shares, paper: pre-built connectors, the Records API, and an ETL lane bring records into RMA iQ with NARA metadata and AI classification on the way in.
Breadth, depth, and a documented seam.
The three things federal records teams keep asking for, and the shape of the whole capture layer.
Meet records where they live.
Pre-built connectors cover the federal stack agencies actually run on: M365, ServiceNow, file shares, scanned paper, and the citizen-facing FOIA.gov, with the full set in the grid below. Login.gov and ID.me integrate for public-portal authentication rather than record capture. The library keeps growing, and each connector respects the source system's permissions and audit trail.
See every connector we maintainBring them in with structure.
Every record that arrives lands in RMA iQ with NARA-mandated metadata already populated: identifier, title, description, creator, date. Fields that don't map cleanly are preserved as custom metadata, and AI can run at the moment of capture, before the record reaches a records officer's queue.
How the capture layer worksWire up the rest yourself.
The Records API is documented and stable. Anything the connectors don't cover, your integration team can wire up directly, or Feith's implementation team can build it with you. AD/LDAP sync ships with the platform, and every capture event emits a webhook downstream workflows can subscribe to.
The Records API approachThe connectors agencies reach for most.
These are the source systems federal teams run on most, each with a production-grade connector maintained by Feith and aware of the source's permissions model. The set keeps growing, and anything outside it is handled by the Records API or the ETL lane.
Connection types
API-first throughout: any system with a documented API can be wired into the capture layer.
Three lanes. One layer.
Most agencies use all three. Which lane handles a given source depends on what the source can offer and what the records team needs out the back.
Records API
The most direct lane. Source systems push records to Feith through documented REST endpoints. It's the workhorse for bespoke line-of-business systems, custom intake portals, and anything the connector grid doesn't cover. The API validates NARA fields at submission, so malformed records are rejected before they reach the archive.
Pre-built connectors
A growing library of federal and enterprise connectors, each a production-grade integration maintained by Feith. Connectors handle authentication, rate limiting, deduplication, and source-system pagination so the records team doesn't have to.
ETL
The migration lane, for what the API and connectors can't reach. Legacy file shares with thirty years of folder structure, database tables from sunset systems, scanned paper, backup tapes. This is where federal records migrations actually happen.
Four operations that run across all three lanes.
Classification
Records are classified against the agency's records schedule (housed in RMA iQ) at the point of capture. The model reads the content and proposes a category; records officers review proposals in batches.
Metadata extraction
Unstructured content (paper, scanned PDFs, free-text email bodies) is read by the extraction model, and NARA-mandated fields are populated from the content itself.
CUI / PII tagging
Records carrying CUI or PII are programmatically tagged at capture by the CUI/PII Connector module, so sensitivity is known before the record reaches a queue. Redaction itself happens downstream, where FOIA Workbench proposes withholdings with exemption codes and plain-language justifications.
Routing
Records can be routed to specific cases, queues, or workflows by content. A record from M365 can be matched to an open FOIA case and added to its evidence set automatically, the integration point with Workflow & Automation.
What guards the layer itself.
The capture layer sits in the path of every record entering RMA iQ. It inherits RMA iQ's ATO posture and adds source-specific protections at each connector.
Credentials to source systems
Managed identity, service principal, or OAuth refresh tokens, stored in the platform's secrets vault. No long-lived plaintext credentials on disk.
In transit
TLS 1.3 between every source and the capture layer. Mutual TLS for source systems that support it.
At rest in the capture buffer
AES-256. Buffer retention is short by default; records move to RMA iQ on a sub-minute SLA in most deployments.
Source-system permissions
Connectors operate under the source's RBAC and see only what the integrated identity is authorized to see at the source.
CUI during AI on intake
The AI operations run inside the platform's trust boundary. CUI-flagged records can be configured to skip the AI lane entirely where agency policy requires human-only handling.
ATO inheritance
The capture layer is in scope for the same ATO as the RMA iQ deployment it feeds. On Feith's FedRAMP Moderate Authorized environment on Azure Government (single-tenant, like every Feith installation) it rides that authorization; the IL4 / IL6 / IL7 modes are separate single-tenant agency-tenant deployments, each with its own ATO that likewise covers the capture layer.
Audit trail
Every capture event is logged (source, timestamp, identity, payload hash, classification outcome, CUI / PII flags, destination ID) and queryable from the same audit surface as RMA iQ.
Air-gapped deployment
The capture layer runs air-gapped. ETL and on-premises connectors need no external network reach, and the Records API can operate on an internal-only network.
The full posture is documented in the platform's System Security Plan, maintained for each ATO and available under NDA to agencies in active procurement.
A migration story from a cabinet-level agency.
A composite of two recent federal migration engagements. Names are anonymized and volumes are illustrative within an order of magnitude, but the shape of the work, the lane usage, and the hard moment in the middle are accurate.
A cabinet-level agency with roughly 30,000 users needed to retire two legacy document management systems and consolidate fifteen years of records into a single NARA-compliant archive, without pausing the four intake streams still running on the legacy systems.
Two weeks into the historical ETL, a records officer running a sample audit flagged a date discrepancy. One legacy system had stored creation timestamps in local time with no timezone metadata. Records that looked created in 1998 might actually be from 2003, depending on which regional office had ingested them, and the records schedule depends on the actual creation date for retention math.
The first three weeks of migrated records had to be re-ingested. Feith's implementation team worked with the agency's data team to write a timezone-normalization step that ran against every record as it moved through the ETL lane, using regional office identifiers to anchor each timestamp. The fix added two weeks to the engagement, and zero records were lost.
- Zero downtime to those intake streams during the migration.
- All historical records ingested with NARA metadata populated, classified against the agency's schedule, and indexed for FOIA search.
- Two legacy DM systems decommissioned within the engagement window.
- The timezone-normalization step is now a reusable component in the ETL lane for any source with the same defect.
What separates this from a horizontal capture layer.
Three structural choices set Feith's capture layer apart from horizontal capture vendors and the capture modules bolted onto general-purpose DM systems. Each showed up in the migration above.
The capture layer and the archive are built by one company.
Most capture vendors ship records to whatever archive the agency owns; the integration is a separate engagement, often with a separate vendor, and the round-trip semantics get negotiated. Feith's capture layer was built against RMA iQ, so the round-trip is engineered end-to-end by one team. Records written through capture are readable through the same identity, with the same metadata, under the same retention policy, on the same audit trail.
Records come to Feith; source systems stay put.
The capture layer goes to the source. It doesn't require source systems to migrate to a vendor cloud. Air-gapped sources stay air-gapped; on-premises sources stay on-premises; the connector model operates under the source's RBAC. Agencies don't give up architectural control of their systems to use Feith for records management.
AI on intake is a native operation.
The four AI operations run as part of the capture pipeline itself. The categorization that runs on capture is Record Insight, the same generative-AI categorization built into RMA iQ — one model layer, one audit trail, whether a record is read at intake or re-examined later.
The same layer, for regulated industries.
The capture layer is in production across federal agencies, but the engine is industry-neutral. Regulated enterprises (life sciences, energy, financial services, higher education) use the same three lanes with a different connector mix.
SAP 
Oracle 
Salesforce 
SQL Server 
DocuSign 
Alfresco 
ADP Enterprise connectors ship on the same release cadence as the federal grid. The Records API and ETL lane are identical across federal and enterprise, and single-tenant architecture is standard for both.
See the capture layer on your stack.
Tell us what systems you need to capture from. We'll show you the connector list, the API surface, and a worked example for your environment.
Contract vehicles
GSA MAS · CDAO Tradewinds
Request received.
We'll reach out with the connector list, API documentation links, and a worked example tailored to the source systems you listed.
Where next
The capture layer is the entry point. Five places to go from here.