File Specification

The normative specification for the two CSV files that feed a flat file source. The Owner Guide explains why each rule exists and how the files are used; this page is the reference an extract developer builds against. Where the two disagree, this page wins — and please tell us, because they shouldn't.

The schemas below are taken from the sources actually deployed in the tenant, not from a template. Every source built so far uses exactly this layout.

Terminology: must is a validation rule — a file that violates it is rejected whole. Should is a strong convention — deviations need to be agreed before the first delivery.

General file requirements

Requirement	Value
Format	CSV per RFC 4180: comma-delimited, double-quote quoting
Encoding	UTF-8, without a byte-order mark. (A leading BOM is tolerated by the pipeline, but emit without one.)
Line endings	\n (Unix) or \r\n (Windows) — both accepted
Header row	Required, first line. Column names are case-sensitive and must exactly match the agreed schema — EmployeeId ≠ employeeId ≠ employeeid
Header column order	Keep it consistent between deliveries in the order specified below — the pipeline normalizes column order against the ISC schema, but a stable order keeps daily snapshots diffable and mistakes visible
Field delimiter	Comma (,)
Quoting	Any value containing a comma, double quote, or line break must be enclosed in double quotes; embedded double quotes doubled (""). Multi-value fields (groups) should always be quoted
Multi-value delimiter	Semicolon (;), inside a quoted field: "OUTLET_MGR;POS_ADMIN;INV_READ" — see the Owner Guide
Row shape	Every row must have exactly the same number of fields as the header
Empty fields	Allowed where the column spec permits: ,, or ,"", both read as empty
Boolean values	Literal lowercase true / false. (0/1 are accepted by ISC but do not use them — true/false reads unambiguously)
Date values	ISO 8601: YYYY-MM-DD for dates, YYYY-MM-DDTHH:MM:SSZ for timestamps
Forbidden content	No emojis; no + in values
Size limits	Account file: 500 MB / ~400,000 rows. Entitlement file: 1 MB
Large files	Over ~400,000 rows, split into chunks named accounts-Part01.csv, accounts-Part02.csv, … — they are processed as one set
Sorting	Account file should be sorted by id
Completeness	Account file is a full snapshot of every account, every delivery — never a delta

Unless a column is explicitly typed above, every value is a string.

File naming

Name the files whatever makes sense for your team — accounts.csv / entitlements.csv if you overwrite each delivery, or date-stamped (accounts-2026-06-02.csv) if you keep a few days of history in the folder. No source-ID prefix is required from you: your drop-off path on the ESB file share identifies your system, and the Capri side adds anything the upload pipeline needs. Just be consistent so your own folder stays readable, and write atomically (write to a temp name, then rename) so a pickup never catches a half-written file.

Account file

One row per account in the application. The standard layout — the one every source built so far uses — is:

id,name,employeeId,givenName,familyName,e-mail,location,IIQDisabled,groups

Your source's exact column set is agreed at onboarding and may be narrower (a system with no name or location data can omit the informational columns) or carry the optional extensions below. Whatever is agreed becomes your schema: deliver those columns, all of them, every time.

#	Column	Required	Value may be empty	Allowed values	Description
1	id	Yes	No	Any string, unique per row	The account's unique identifier in the application (login name, account number, GUID — whatever the application keys on). This is the source's identity attribute: a blank or duplicate id fails the file. It must be immutable — if an export regenerates or renumbers IDs, ISC sees every row as a brand-new account and duplicates the population. Use a stable internal key, never an ordinal position.
2	name	Yes	No	Any string	Human-readable login/username on your system. This is the source's display attribute — what certification reviewers see.
3	employeeId	Yes	Only for agreed exceptions	The Workday employee number, exactly as issued	The correlation key — matched against the Workday-fed identity to tie the account to a person. Rows without one load but correlate to nobody; every population you cannot supply an ID for (service accounts, external contractors) must be declared and agreed per source. Multiple rows sharing one employeeId are valid (one person, several accounts).
4	givenName	Yes	Yes	Any string	First name as your system records it. Informational.
5	familyName	Yes	Yes	Any string	Last name as your system records it. Informational.
6	e-mail	Yes	Yes	Email address	The account's email on your system, which may differ from the HR-of-record address (mid-rebrand, both @capriholdings.com and @michaelkors.com exist — send whichever the account actually has). Header is e-mail, with the hyphen — a column named email does not match the schema and its values never load. Informational; not used for correlation.
7	location	Yes	Yes	Any string	Free text. Quote when it contains commas: "Milan, IT".
8	IIQDisabled	Yes	No	true | false (literal, lowercase)	true when the account is disabled in the application. Disabled and terminated users stay in the file with true — a dropped row is a deletion, not a disable, and this column is the only way ISC learns an account is inactive. Read as a string: true, false, and empty are three different values, so populate every row.
9	groups	Yes	Yes	;-separated entitlement ids	The entitlements this account holds. Every value must appear as an id in the entitlement file. Empty means the account holds no entitlements. No spaces around ;; no ; inside an entitlement id. Quote the field.

"Required: Yes" means the column must be present in the header even when its values are empty. Do not add, remove, or reorder columns without agreeing a schema change first — an unknown column rejects the whole file.

Optional extension columns

Available when your system has the data — agree them at onboarding so they're added to the source schema before your first delivery:

Column	Type	Description	Example
displayName	string	How your system shows the person's name, when it differs from HR (preferred name, former name, alias). Omit the column if your system uses the HR name unchanged.	J. Doe (Outlet 451)
IIQLocked	boolean string	Same shape as IIQDisabled, for locked accounts (e.g. after failed logins).	false
accountCreatedDate	date	When the account was created on your system. Useful for audit.	2024-03-15
lastLogin	timestamp	Most recent login. Identifies dormant accounts in certification reviews.	2026-05-30T08:14:22Z
roles	multi-valued string	A second entitlement column, for systems where groups and roles are genuinely separate categories. Same ; rules as groups.	"ROLE_FIN_APPROVER;ROLE_BUDGET_EDIT"

Something unique to your system that isn't listed — a contractor flag, a license tier, a risk score? Ask; a schema addition is a small change.

The deployed ISC schema also carries a manager attribute that ISC adds to every delimited file source automatically. Do not include it — the upload pipeline supplies it as an empty column; it is listed here only so nobody "fixes" the mismatch by editing their extract.

Example account file

id,name,employeeId,givenName,familyName,e-mail,location,IIQDisabled,groups
JDOEJC,Jane Doe,123456,Jane,Doe,jane.doe@example.com,"Milan, IT",false,JC_HFM_Submitter_Americas;JC_HFM_Viewer_UK
RROEMK,Rick Roe,234567,Rick,Roe,rick.roe@example.com,New York,false,JC_HFM_Viewer_UK
SLEFTC,Sam Left,345678,Sam,Left,sam.left@example.com,London,true,JC_HFM_Viewer_UK
SVCRPT,Reporting Service,,,,,Datacenter,false,JC_HFM_Viewer_UK

(Anonymized. Row 3 is a leaver — present, disabled. Row 4 is a service account with an agreed empty employeeId.)

Entitlement file

One row per distinct entitlement (group, role, permission) the application exposes. Header, exactly:

id,name,displayName,description,owner,requestable,privileged,entitlementType

#	Column	Required	Value may be empty	Allowed values	Description
1	id	Yes	No	Any string without ;, unique in the file	The entitlement's identifier — exactly the string used in the account file's groups column, case-sensitive. Duplicates fail the file.
2	name	Yes	No	Any string	Usually identical to id.
3	displayName	Yes	No	Any string	What requesters see in the access catalog. Written for a human: Jimmy Choo HFM Submitter - Americas Entities, not JC_HFM_SUB_AM.
4	description	Yes	No	Any string, ≤ 2,000 characters	What the access lets someone do, and what makes it sensitive (SOX-relevant, customer PII, admin rights). Read by approvers, fulfillers, and certifiers.
5	owner	Yes	No	Email address resolving to an identity in the ISC tenant	The accountable person. Provisioning tasks route to them; certifications may be assigned by them. Must be a real, monitored person — see the Owner Guide.
6	requestable	Yes	No	true | false (literal, lowercase)	true: users may request this through self-service. false: kept out of the catalog — use for anything that should not be self-service, admin access in particular.
7	privileged	Yes	No	true | false (literal, lowercase)	true for admin-level access: prioritized in certifications and included in privileged-access reporting.
8	entitlementType	Yes	Yes	Any short category string	A category of your choosing (Financial Consolidation, Platform Administration, …). Searchable, usable in access profile filters.

Columns 1–4 and 8 become attributes of the entitlement in ISC. Columns 5–7 (owner, requestable, privileged) are ISC governance properties applied after the load — the split is our mechanics, not yours; supply all eight columns.

Technically only id and name are enough for a file to load — but an entitlement without a displayName, description, and owner is an anonymous code that certifiers rubber-stamp and provisioning tasks can't route. The eight-column layout is the working minimum for this program; treat the extra effort as the highest-leverage part of the whole extract.

Optional extensions, same as the account file (agree at onboarding): created and modified (ISO 8601 dates) when your system tracks when an entitlement was defined and last changed.

Example entitlement file

id,name,displayName,description,owner,requestable,privileged,entitlementType
HFM_Admin,HFM_Admin,HFM Administrator,"Full administrative control over the HFM application, including security and metadata. SOX-relevant.",sam.roe@example.com,false,true,Platform Administration
JC_HFM_Viewer_UK,JC_HFM_Viewer_UK,Jimmy Choo HFM Viewer - UK Entities,Read-only access to UK entity financial consolidation data.,sam.roe@example.com,true,false,Financial Consolidation

Cross-file rules

1. Referential integrity: every value appearing in the account file's groups column must exist as an id in the entitlement file. Orphaned references fail the account file. The reverse — an entitlement no account holds — is allowed and produces only a warning.
2. Load order: the entitlement file loads before the account file. Deliver them together.
3. Consistency across deliveries: same columns, same order, same delimiter conventions every time. A layout change is a schema change on the ISC side and must be coordinated before the extract changes.

Validation and rejection semantics

Every delivery is validated before anything touches the tenant. Failures come in two grades:

Whole-file rejection — nothing loads, fix and resend the entire file:

• Header missing, or a column name unknown to the source's schema (the error names the column)
• A required column absent (the error names it)
• Ragged rows (field count differs from the header)
• Duplicate account id or entitlement id within the file; ; inside an entitlement id
• A groups value with no matching entitlement id
• Not UTF-8 decodable, or over the size limit

Row-level skip — the rest of the file loads; skipped rows are counted as ignored in the aggregation report:

• A row with an empty id
• A malformed value in a typed column (bad date format, non-boolean in a boolean column)

Row-level skips are quieter than rejections and therefore more dangerous: the delivery "succeeds" while accounts silently drop out. Watch the ignored count in the feedback you get, and treat any non-zero value as a defect in the extract.

Delivery

Two supported paths — file drop on the encrypted ESB file share (the default), or a direct API push for teams with automation maturity. The CSV format on this page is identical for both. See Delivery Options for the mechanics, credentials, and error handling, and Refresh Cadence and Delivery for scheduling.

SailPoint references

The official documentation behind this specification, for anyone who wants the vendor's own words:

• Integrating SailPoint with Delimited File Source — the connector this source type runs on
• Account Attributes — the delimited file account schema reference
• Handling Multi-Valued Attributes — how multi-value fields like groups are modeled
• Loading Account Data — aggregation from the ISC side
• Aggregating Entitlements — the entitlement half
• import-accounts · import-entitlements — the API operations behind Delivery Options Option B
• Assigning Source Accounts to Identities — how employeeId correlation works