JRDM XML explained: a practical map of the Job Requisition Data Model.

1. What a JRDM file is, and how to recognise one.

A Job Requisition Data Model template is the XML definition of one requisition form: which fields exist on it, what type each field is, which roles can see or change each field at each stage, and which job application template it is joined to.

There are two ways to change one, and which you can use depends on the access you have.

Manage Templates, in Admin Center, edits the template through a UI. You can add fields, move them, set permissions, and export the current XML. You cannot import an edited XML file from there. The UI is practical for small changes, but a long series of edits becomes a long series of clicks.

The XML itself is the other route. Export it from Manage Templates or Provisioning, keep an untouched copy, and work on a second copy. Loading the edited XML requires Provisioning. SAP's documented support boundary is that customers do not have Provisioning access and normally work through an implementation partner, Account Executive, or Technical Support.

That split is worth understanding before you plan a piece of work. If you cannot import, you can still export the file and read it, which is often the faster way to answer a question like why a field is hidden from a hiring manager at one status. You can also prepare a reviewed change and hand it to whoever can load it.

The quickest way to tell the four primary Recruiting XML template types apart is the root element. Each uses a distinct one:

Similar filenames and field ids do not identify the template type. The root element does.

Near the top of the file, the DOCTYPE points at a DTD, a Document Type Definition. It is a grammar: it lists which elements are allowed, which may contain which, and how many of each. SuccessFactors checks the file against it on upload, which is why a template can be perfectly valid XML and still be rejected.

One of its rules is worth knowing, because you will meet it. A <field-permission> block needs at least one role, at least one status, and at least one field. The description is optional. Provisioning rejects a field-permission block with no field reference; section 5 covers what that means in practice.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE job-req-template PUBLIC
  "-//SuccessFactors, Inc.//DTD Job Requisition Template//EN"
  "job-req-template.dtd">
<job-req-template type="jobReq" spell-check="false">
  <template-name><![CDATA[Linked Starter]]></template-name>
  <template-lastmodified>9/12/26 12:00 AM</template-lastmodified>
  <supported-languages>
    <lang><![CDATA[en_US]]></lang>
  </supported-languages>

Notice what is not here. There is no template id element. A requisition template identifies itself by <template-name>, and it joins to its job application template by name too, through <application-template-name> at the very end of the file. Filename similarity proves nothing, and neither does a matching set of field ids.

2. The top-level map, in order.

This is the common spine of a requisition export, in the sequence used by SAP's guide and the exports reviewed for Permistry. Many sections are optional, so no single file needs every row. The DTD remains the authority for the exact structure accepted by your tenant.

You may also meet elements that are present in exports but not explained in the current administration guide, including default-listing-layout-id. Preserve unfamiliar source rather than treating this table as permission to remove it.

Two warnings about order, because it is a thing that can be misunderstood.

1. This is the order templates are written in, which is not the same as an order the DTD requires. Treat it as the shape to expect, not a rule to enforce.
2. The order of permission blocks relative to each other affects how the file reads, and how it comes back out of an export. What it does to the access a role actually gets is subtler than the plain reading of the ordering sentence in SAP’s administration guide, and it is the whole subject of the next guide, How SuccessFactors JRDM field permissions resolve. Do not reorder blocks expecting to change access until you have read it.

3. Field definitions: the catalogue.

Every field on the requisition is one <field-definition>. Four attributes appear on essentially all of them: id, type, required, and custom.

Standard fields and custom fields.

The custom attribute tells you which is which.

• custom="false" is a standard field. You still choose whether it appears on your template, but the id and what it means come from SAP’s fixed list.
• custom="true" is a field your tenant defined. Its id is local to that tenant and template.

A standard field id has a product-defined meaning, although its label, permissions, and supporting tenant configuration can vary. A custom field id means whatever that tenant defined it to mean.

There is a complete synthetic sample you can open if you want to see standard, operator, and custom fields together. It is a learning file, not production configuration.

The Provisioning field selector offers 21 types.

In the Provisioning form tested for this guide, these were the 21 available values:

• attribute, bool, competencies, currency, date, derived, enum, instruction, jobCode, jobRole, multiattachment, number, object, operator, operatorTeam, percent, picklist, questions, richText, text, textarea

Do not treat upload acceptance as proof that a type is supported. Controlled imports have accepted an unrecognised value without making it a working field type, moving the failure from import time to testing.

Three choices open more controls in Provisioning.

When you add a field through Provisioning, three selections expose additional type-specific inputs:

Where the form’s labels and the XML disagree.

The form and the file it produces do not always use the same name or shape for the same setting. The XML forms below are the ones to look for when reviewing an export.

When the two disagree, the XML is what gets loaded. The form label is a description of the field, not a specification of it.

This is the kind of mistake that is cheap to make by hand and tedious to find afterwards. Permistry writes these structures in the shape SuccessFactors expects, and flags the ones already in a file that are not, before you upload rather than after.

<field-definition id="status" type="picklist"
    required="false" custom="false">
  <field-label><![CDATA[Status]]></field-label>
  <picklist-id>reference-status</picklist-id>
</field-definition>
<field-definition id="currency" type="enum"
    required="false" custom="false">
  <field-label><![CDATA[Currency]]></field-label>
  <enum-value value="REFERENCE_A" style="">
    <enum-label><![CDATA[REFERENCE A]]></enum-label>
  </enum-value>
  <default-value>REFERENCE_A</default-value>
</field-definition>

That empty style attribute is worth noting. Every enum-value in the exports measured for this guide carries it, while SAP’s published example leaves it out. The published material reviewed here does not explain its purpose. Preserve it: an attribute you do not understand is not one to tidy away.

The order of elements inside a field.

A <field-definition> contains other elements: its label, its help text, and whatever extra configuration its type needs. Those go in a fixed sequence, and a file that puts them in a different one can be refused on upload.

The sequence is:

1. field-label, the name shown on the form.
2. field-description, the help text under it.
3. then whichever one of picklist-id, field-criteria or enum-value the field’s type calls for.
4. default-value last, after the values it chooses between.

Custom ids and numbered standard fields are different things.

A tenant-defined custom field uses a unique id chosen in the XML and is marked custom="true". SAP advises using underscores rather than hyphens in custom field ids. If the field must be reportable, its XML id is mapped separately in Provisioning under Configure Reportable Custom Fields.

SAP currently documents 100 text, 40 number, 110 picklist, and 30 date reportable mappings for each Recruiting XML definition. That is a reporting limit, not a naming rule for the field id. Check both the XML and the reportable-field mapping before promising a new field downstream.

Labels, languages, and required.

A field can carry an unqualified <field-label> plus separate <field-label lang="..."> elements. <supported-languages> supplies the ordered set those draw from. The values are independent XML elements: changing the default label does not create or update its translations.

required="true" does more than mark the form. It makes the corresponding OData property mandatory, and omitting it returns [COE0018] <field> required. A field made required for the form’s sake can therefore break an integration that was working the day before.

4. What the file says about layout, and what it does not.

Does the template fully describe the form’s layout? No. The optional section-name elements label parts of the form, but the file has no general-purpose panel, tab, or column structure that assigns fields to a visual layout.

What it does express is a sequence. The order of the <field-definition> elements is the order the fields appear on the form. That is what the up and down controls in Manage Templates are moving: each click rewrites the position of one definition in the file.

Relative order is all it controls. Exact spacing, columns and responsive behaviour are not in the template.

Move a field and watch both sides change. This is the same operation as the up and down controls in Manage Templates, shown next to what it does to the file.

<field-definition id="jobTitle" type="text"/>
<field-definition id="numberOpenings" type="number"/>
<field-definition id="cust_reference_rationale" type="text"/>
<field-definition id="cust_reference_preference" type="picklist"/>
<field-definition id="cust_reference_availability" type="date"/>

The grouping pattern measured in the available templates is a field of type instruction carrying header="true". Permistry treats that as the start of a section running until the next header. The same field type with header="false", or with no header attribute, is treated as an inline note.

Treat that grouping as a guide rather than a guarantee. SAP documents relative field order, but the published material reviewed for this guide does not define what header="true" means to every renderer.

The XML alone is therefore not enough to reproduce a tenant’s form exactly. What finally renders also depends on business rules, Role-Based Permissions, picklist configuration, tenant settings, the requisition’s own data, and which SAP experience the user is in.

5. Permission blocks.

Four permission structures matter in a routine JRDM review. They are easy to confuse because they use the same operator codes but control different things and do not share one grammar.

Field permissions.

A <field-permission> block says: these roles, at these statuses, get this level of access to these fields. It is the single most important structure in the file, and most of what you will ever change lives in one.

As covered in section 1, a block needs at least one role, at least one status and at least one field. A block that has lost its last field reference is refused on upload rather than ignored.

<field-permission type="read">
  <description><![CDATA[Read example]]></description>
  <role-name><![CDATA[V]]></role-name>
  <role-name><![CDATA[R]]></role-name>
  <role-name><![CDATA[G]]></role-name>
  <status><![CDATA[pre-approved]]></status>
  <field refid="id"/>
  <field refid="status"/>
  <field refid="title"/>
</field-permission>

The requisition slice has exactly three statuses: pre-approved, approved and closed. These are the internal status values, and there are only ever three. The status picklist field, which you will also see in the file, is an unrelated thing that happens to share the word.

The two field-permission types documented for ordinary access are read and write. With neither grant, the field is normally hidden for that role and status. One SAP-sourced starter file reviewed for Permistry also contains type="none"; its runtime effect is not documented or tenant-tested, so do not use it as a deny rule without evidence.

SAP makes two recommendations here, and they are recommendations rather than rules. Set up a separate permission block for each operator, even when two operators share a permission set, because it makes later changes tractable. And define read permissions before write permissions, so that the greater permission applies where they overlap.

Grouping blocks by stage, pre-approved then approved then closed, is a tidiness convention rather than a rule. SAP does not require it.

Which brings up the thing that actually goes wrong with permission blocks over time. They accumulate. A template that started with a clean block per operator picks up years of small changes, each one appended by whoever needed a field visible that afternoon, and ends up with overlapping blocks that nobody wants to touch because nobody is certain what depends on them. By the time it is a problem, answering one access question by hand means reconciling every matching block.

This is the state an organically maintained template can end up in, and it is the problem Permistry was built for: it resolves the supported read and write blocks into one answer per field, role, and status, so you can see the result rather than reconstructing it by hand.

How these blocks combine into a single answer for one role at one status is a separate question, and the answer is not the one most people carry around. It is the subject of the next guide, How SuccessFactors JRDM field permissions resolve, which is in progress and will appear on the guides index.

Feature permissions.

A <feature-permission> is a type, a description, one or more role names, and exactly one status. There is no <field> element inside it.

The difference that costs people time is this. A feature permission controls whether a role can do something at a given applicant status. A field permission controls whether a role can see or change a field. Both live in the same application-status-config section, a few lines apart, and they are constantly mistaken for one another when a permission is not behaving as expected.

If an operator can see a field but cannot take the action next to it, the field permission is not the thing to look at.

Button permissions.

A <button-permission> grants a named action to named operators. SAP documents closeReq and reopenReq, and states explicitly that a <status> element is not supported in these blocks. Evergreen child linking requires the exact id LinkChildRequisitions.

Close is natively available on approved requisitions and Reopen on closed ones, and the close grant is what supplies the Cancel action while a requisition is pre-approved.

Button blocks take no <status>, so unlike field permissions they are not scoped to a stage of the requisition.

Candidate email permission.

<candidate-email-permission> is a separate, optional top-level block. SAP documents it as a way to restrict the Email action on an application record to named operators. It can appear only once and cannot be scoped by applicant status. If it is absent, all operators can access the Email action.

Operators and role codes.

The base roles use single-letter designators. Seven have a primary operator field and a dependent team field. V has vTeam but no primary field, and C is the candidate rather than a requisition operator field:

A team field is dependent on its primary field. If a template omits coordinatorName but somebody is saved into coordinatorTeam, they appear on the requisition and still cannot open it as that operator. The failure is silent and looks exactly like a Role-Based Permissions problem. vTeam is the documented exception: it assigns V without a matching primary field.

V is the approver role. It covers participants on the approval route map and can also be assigned through vTeam. C is the candidate, and appears only where multistage applications are in use.

Relational codes.

Not every code in a file is on the list above, because some are built rather than chosen. A relational code is an operator letter plus a suffix naming a relationship, and it points at whoever stands in that relationship to the operator.

The important caveat: a relational code in the file does not by itself grant anyone access. Relational operators still have to participate in the route map. Seeing GM+ in a block tells you what was intended, not what a given manager will actually be able to open.

And then there is J, which is in your template whether you put it there or not. It is a technical role the system generates during upload, and it controls which fields appear in the legacy Recruiting Reports link. Read-only, requisition slice only, all three statuses, and typically covering most of the field catalogue, because it is generated rather than curated.

The part worth knowing: you cannot remove it. Delete the J blocks, upload the template, and Provisioning writes them back. That is normal behaviour, not a caching problem and not a failed import. It also has a use: when the legacy report shows a partial field list, SAP’s own remedy is to delete the J permissions deliberately and re-upload, letting Provisioning regenerate them cleanly.

J makes a broader point too. SAP's statement that custom operators are not supported does not mean every valid role is one of the base designators in the operator table. Relational designators and the system-generated J role extend the set for specific, documented reasons.

6. Listing fields and mobile fields.

Both of these are small, both are widely misread, and the misreadings are expensive.

<listing-fields> names requisition fields that can be used as tokens in job descriptions, headers and footers. It does not control the columns on the Job Requisitions list page. People reorder it expecting the list page to change, and nothing happens.

<mobile-fields> controls what an approver sees while reviewing and approving a requisition in the SuccessFactors mobile app. It is not candidate Mobile Apply. Job Code Entity fields are not supported there, and SAP warns that more than fifty references can cause errors, with the practical limit lower still because of scrolling.

Only one section of each kind is supported. Both are measured as containers whose <field refid> children appear in source order; whether changing that child order has any runtime significance is not established by the documentation retrieved so far.

7. The application slice inside the requisition.

Near the end of the file, application-status-config opens what is effectively a second permission space living inside the first. Reading one as if it were the other is the most likely serious misreading of a JRDM.

Requisition field permissions use refid and apply at the three requisition statuses. Application field permissions inside this section use application-field-id and apply at the applicant statuses, of which there can be dozens. Same element name, different key, different statuses.

<application-status-set name="..."/> is a reference, not a definition. It names a status set configured in Admin Center, and OData exposes it as statusSetId. Renaming it repoints the template. It renames nothing in the tenant, and a name that matches nothing at all is not rejected on import.

Multistage applications are why this section carries permissions at all. For single-stage applications, operator and candidate field access is determined in the job application template. For multistage, Recruiting operator permissions primarily move to the job requisition template.

Current SAP sources disagree on the exception list. The dedicated multistage Help topic keeps id, resume, coverLetter, statusId, and comments in the Application template; the current administration guide's summary names only resume, coverLetter, and statusId. Preserve existing references to all five and verify the target configuration before moving or removing them. That migration is the subject of a separate guide.

Near the end of the file, <application-template-name name="..."/> supplies the join key. An association is evidence of a link, not a second working file: the application template still has to exist and its internal <template-name> must match exactly. An optional <candidate-email-permission> can follow the association.

A last detail that looks like a typo and is not. The exporter writes <field application-field-id="x" /> with a space before the slash, and <field refid="x"/> without one, with no exceptions across thousands of occurrences of each. It is semantically meaningless. It matters only because a file you did not intend to change should come back out byte for byte.

8. What the bytes mean.

If you hand-edit these files, four measured details will save you a confusing afternoon.

Line endings are LF, a single line feed character, which is the Unix convention. They are not CRLF, a carriage return followed by a line feed, which is what some Windows editors write by default. There is also no byte-order mark at the start of the file. If your editor quietly converts either, a one-line edit can appear as a whole-file diff even when the XML means the same thing.

Indentation is not uniform, which catches people out. field-permission children are indented one level deeper than their block. field-definition children sit at the same depth as the definition itself. Copying the spacing from one to the other gives you a file that is valid and visibly wrong to the next person who opens it.

Do not use XML comments as durable notes. In a controlled test, a comment added after the document declaration and DOCTYPE imported successfully and disappeared from the next Provisioning export. That does not prove how every possible comment position behaves; it does prove that comments are not a reliable place for a version or a note to the next consultant.

9. What a JRDM cannot tell you.

The most useful thing to know about a configuration file is where it stops. Every answer below is no, and each one is a tenant check rather than something a smarter reader could extract from the XML.

• Can it tell you a named user’s effective access? No. V is additional access for route-map or vTeam participants, and the route map is not in this file. An offline matrix resolves each designator independently; what a person actually gets stays a tenant check.
• Can it tell you what is in a picklist? No. The JRDM carries the picklist id, not its values. Inspect the target tenant's picklist configuration; the same id can resolve differently between environments.
• Can it tell you what the form will look like? No. See section 4.
• Can it tell you about Role-Based Permissions or MDF object validity? No, and not because the answer is hard: a requisition template contains no role-based permission element and no MDF object definition. Those live elsewhere entirely.
• Can it prove that a button will appear? No. It can show the template grant, but product state, tenant configuration, and other documented runtime conditions still decide availability.
• Can it tell you whether a language is usable? No. Adding a locale to <supported-languages> creates no labels and makes no claim that the tenant or Career Site Builder is ready for it.

None of this makes the file less useful. It makes the boundary explicit, which is the difference between a review you can sign and a review that merely looks thorough.

10. Sources.

11. Where this goes next.

Two guides follow directly from this one. Neither is published yet; both will appear on the guides index.

Open beta. No account, and your files stay on your machine.