10.1 Direct-to-Profile Requirements


Direct-to-Profile processing involves more I/O activity than other ILL Direct Request processing options. Therefore, requests using Direct-to-Profile take longer to process. This option may not be suitable for systems that allow patron-initiated ILL, since the system may keep patrons waiting for a response.

To be sent to a lender, an ISO-10161 ILL-Request for Direct-to-Profile must:

  • Satisfy ILL Direct Request requirements for acceptance
  • Match a WorldCat bibliographic record
  • Match a profile defined by the borrowing library
  • Have enough lenders
  • Satisfy other OCLC ILL requirements

Requirements for acceptance

The requirements for acceptance are:

  • All fields required by ISO-10161must be present
  • transactionId must be universally unique
  • protocolVersionNum must have the value version-1(1) or version-2(2)
  • The OCLC institution symbol of the borrowing library must be included in the request. (See initialRequesterId and requesterId in "Table: Specifications and Mapping" in chapter 9.)
  • One of the values of illServiceType must be loan(1) or copyNonReturnable(2)
  • title must be present in itemId
  • The first request of a connection must contain an OCLC ILL authorization number and password. (See illrequestExtensions in "Table: Specifications and Mapping" in chapter 9.)

Match a WorldCat bibliographic record

In order to match a WorldCat bibliographic record, the request must contain an ISBN, ISSN, or OCLC number.

Match a profile

ILL Direct Request matches profiles based on attributes of the request and attributes of the matching bibliographic record. The request attributes are:

  • request source
  • ILL service type
  • patron status
  • patron department
  • patron max cost
  • need before date

A request must meet the following requirements to match a profile:

  • If your library has profiles based on the attributes listed above, the request must include the attributes
  • The ILL service type must be loan(1) or copyNonReturnable(2)
  • The scheme used for request source, patron status, and patron department must be the same as used in the profiles
  • Any of the attributes entered by the patron must be validated

Have enough lenders

The request may contain lenders or it may rely on ILL Direct Request to find lenders based on the matching bibliographic record and the custom holdings path named in the matching profile. (Custom holding paths are records of preferred lenders based on custom groups defined in the OCLC ILL service by your library. Your ILL staff assign a unique name to each custom holdings path they define.)

The valid lenders in the request and the lenders found by ILL Direct Request must satisfy the minimum number of lenders specified in the matching profile. If they do not, ILL Direct Request puts the request in your library’s Review File.



If the request does not contain lenders, then ILL Direct Request automatically tries to find lenders. If the request contains lenders, then ILL Direct Request does not try to find more unless permissionToChangeSendToList (part of thirdPartyInfoType) is set to true.


If preference (part of thirdPartyInfoType) is set to ordered, ILL Direct Request does not change the order of lenders in the request. If an invalid lender is found before the minimum number of lenders is satisfied, ILL Direct Request puts the request in the Review File.

See section 3.1 for details about preference and permissionToChangeSendToList.

Satisfy other OCLC ILL requirements

To be sent to the first potential lender, the request must meet these additional requirements:

  • If present, needBeforeDate (under searchType) must contain a valid date that is today's date or later
  • If present, copyrightCompliance must have the value ccg or ccl (not case-sensitive)
  • If paymentMethod (in OCLCILLRequestExtension) is present and set to ifm (not case-sensitive), the request must contain maximumCost (under costInfoType). The monetaryValue must be valid for IFM. The currencyCode, if present, must be usd (not case-sensitive)
  • Contain postalAddress under deliveryAddress or match a profile that contains the name of a constant data record that includes a :SHIP TO: field

Failed Requests

If the request fails to meet any of the requirements for acceptance, it is rejected. ILL Direct Request sends a message to your system identifying the rejected request. If the request is accepted, but fails one of the other requirements, ILL Direct Request puts it in your library’s OCLC ILL Review File with an appropriate error message in the field :DIRECT NOTES:.

Incomplete requests

If an ISO-10161 ILL-Request is incomplete and the request matches a profile that contains the name of a constant data record, then data from the constant data record is applied when ILL Direct Request creates an OCLC ILL request.

Constant data considerations

Constant data records are templates of often-used data defined by your library that can be automatically transferred to a workform in OCLC ILL. ILL staff assign a unique name to each constant data record they define. Data from the ISO-10161 ILL-Request takes precedence over data from the constant data record. For example, if the ISO-10161 ILL-Request contains :MAXCOST:, then :MAXCOST: is not applied from constant data. Your library must decide which data should be supplied in the ISO-10161 ILL-Request and which data should be omitted so it can be supplied by a constant data record.

The following fields in an OCLC ILL record may be supplied by a constant data record if they are not furnished in the ISO-10161 ILL-Request.

:NeedBefore: :AFFILIATION:


Direct-to-Profile processing requires the element titleOfArticle to Produce serial requests. If omitted, these requests are sent to the Review File.


Direct-to-Profile processing uses several types of OCLC records defined by your library:

  • Direct Request profiles
  • Custom Holdings groups and paths
  • Constant data records

To fully test Direct-to-Profile, you must have these types of records in the test database. You may create them in the test environment, or, if your library has these records in production, ask OCLC to copy them to the test database. Once in the test database you can edit them. Records created or modified in the test environment have no effect on the production system or production database.

A good title for testing

A good bibliographic title for testing has a lot of locations attached to it. A good one to use is In Search of Excellence: Lessons from America’s Best-run Companies (ISBN:0446378445; OCLC:9684530). You may want to use this title in your Direct-to-Profile test request because it is likely to be held by some of the institutions in your library’s custom holdings path.

Testing in the production system

You may choose to test Direct-to-Profile in production. There are advantages and disadvantages to testing in production:

The advantages are:

  • Access to WorldCat instead of a small subset of bibliographic records in the test environment
  • Production is always available; the test environment may sometimes be down
  • Your library may have custom holdings paths and constant data records in production so changes made for ILL Direct Request only need to be made once

The disadvantages are:

  • Your library incurs a charge when Direct-to-Profile finds lenders
  • If your library uses one of the OCLC services that puts requests in the Review File, then you must be able to distinguish your test requests from the real ones
  • Fewer diagnostics running in production environment

If you choose to test Direct-to-Profile in production, set the Produce? option in your profiles to no until you are ready for requests to be sent to lenders.

Note: You cannot test in the production environment until OCLC has reviewed your request in the test environment.