External contacts
Resolve partner, contractor, or customer contacts exported from a CRM or partner system.
“Which partner contact should receive this escalation?”
Roster for CSV
Bring users, groups, and memberships into Roster from controlled CSV files.
Use CSV when your organizational data comes from an HR export, legacy system, customer database, partner directory, or another source without a live Roster connector. Roster reads normalized users, groups, and membership relationships from local storage, S3-compatible object storage, or SFTP.
Last verified 07/13/2026
Participant resolution without a live directory API
Not every organization or workflow uses Entra ID, Okta, Google Workspace, Workday, or LDAP as its direct source.
Relevant participants may come from a legacy HR application, an ERP export, a contractor database, a partner roster, a customer-account list, a regional operations system, a controlled spreadsheet workflow, or a custom internal database.
“Where is this data coming from?”
It asks:
“Who manages the Acme implementation?”
“Which partner contact should receive this escalation?”
“Who should approve this request for the Eastern region?”
“Which temporary project team owns this task?”
The CSV connector provides a stable ingestion contract for these environments—so Roster can resolve responsibility without embedding partner or contractor emails in application code.
How Roster reads CSV data
Files can be mounted locally, read from S3-compatible object storage, or fetched over SFTP.
For local mode, mount the CSV files under ${ROSTER_DATA_DIR}/connectors/csv. In Docker, mount the directory through the Roster /data volume.
Field mappings let Roster consume an existing controlled export without requiring the source system to rename every column.
Selected records are materialized in Roster. The scheduled refresh updates the records and memberships used by participant resolution.
What you can resolve
Regional and temporary teams
Route responsibility to teams that live outside your primary identity directory.
“Which temporary project team owns this task?”
Legacy-system ownership
Bridge legacy ERP or HR exports into participant resolution without a live API.
“Who manages the Acme implementation?”
Business-unit approvers
Map exported business units to approver participants.
“Who should approve this request for the Eastern region?”
Delegated coverage
Overlay Roster delegations on top of CSV-derived membership.
“Who is covering the partner escalation queue today?”
From an export to participant resolution
CSV provides the directory records. Roster provides the project, participant, metadata, and delegation model.
Use stable external IDs that do not change when names or email addresses change.
Design external IDs and participant associations carefully so a native connector can replace CSV later with a controlled migration.
Use CSV-backed context from every Roster surface
Once CSV records back Roster participants, the same organizational context is available across every Roster surface.
MCP
Let an MCP-compatible AI client resolve external or contractor responsibility.
REST API
Add CSV-backed resolution to internal apps and workflow engines.
CLI and CI
Resolve ownership from the terminal or a pipeline without a live directory API.
Roster platform
Administrators associate CSV-derived records with participants, configure field mappings, and manage delegations.
What Roster reads
| CSV data | Used by Roster | Materialized in Roster |
|---|---|---|
| Stable user ID | Yes | For selected users |
| Username | Yes | For selected users |
| Yes | For selected users | |
| Display name | Yes | For selected users |
| Stable group ID | Yes | For selected groups |
| Group name | Yes | For selected groups |
| Group email | When provided | For selected groups |
| User-to-group membership | Yes | Yes |
| Passwords | No | No |
| Authentication secrets | No | No |
Required file — users.csv:
external_id,user_name,primary_email,display_name
user-001,user001,user001@example.com,User 001Required file — groups.csv:
external_id,display_name,mail
group-001,Engineering,engineering@example.comRequired file — user-groups.csv:
user_external_id,group_external_id
user-001,group-001Your source files do not need to use Roster's default column names — configure field mappings instead:
{
"field_mappings": {
"users": {
"external_id": "employee_id",
"user_name": "login",
"primary_email": "email",
"display_name": "name"
},
"groups": {
"external_id": "team_id",
"display_name": "team_name",
"mail": "team_email"
}
}
}Only include columns required for the routing use case.
Storage modes and scheduled refresh
The CSV connector supports three storage modes and refreshes on a configured schedule.
Storage modes
local — files mounted into the Roster data volume. s3 — files read through object storage. sftp — files read through an SFTP source.
Scheduled refresh
Files are read on the connector's schedule. Selected records and memberships are updated in the materialized Roster state used by REST, MCP, CLI, and Resolve.
Operational requirements
Treat the CSV feed as a production data interface rather than an ad hoc spreadsheet.
- 01Use stable external IDs
- 02Maintain a documented schema
- 03Validate required columns before publishing
- 04Generate files through a repeatable process
- 05Refresh on a predictable schedule
- 06Use atomic file replacement
- 07Keep exports under change control
- 08Restrict storage access
- 09Encrypt S3 or SFTP transport and storage
- 10Monitor failed or incomplete refreshes
- 11Preserve a recoverable previous version
Avoid changing external IDs when a person's name, email address, or team changes.
For local mode, mount files under:
${ROSTER_DATA_DIR}/connectors/csvIn Docker, mount the directory through the Roster /data volume. Use durable storage so files remain available across restarts and upgrades.
Example: route work to external project contacts
A company maintains implementation partners in a customer-management system that exports CSV files nightly. The export contains partner contacts, customer implementation groups, and contact-to-group relationships.
A workflow asks:
“Who should receive the implementation escalation for Acme?”
Roster evaluates:
- The Acme project
- The Implementation Escalation participant
- The CSV-derived user or group
- Relevant customer metadata
- Any active Roster delegation
The workflow receives the appropriate contact without embedding partner emails in application code.