Integrations Part- 2

Access and Manage Subscriptions

1. Select Tools → Integrations → Administration..

2. A Candidate Export might be available.

   1. If you do not see this Integration Type, select Actions → Add Integration type.

   2. Select the Candidate export Integration Type and select Continue.

   3. Ensure HR status is selected, and Talent record launch is unchecked.

   4. Select Save.

      

3. Select the Subscription admin icon.

   

4. The [ Subscription administration] screen displays any Common Service or BrassRing to Onboard candidate export subscriptions that have been set up.

   1. To manage existing Subs criptions, select the View Settings or Edit Settings icons as needed.

5. Select Add subscription.

6. Select the Subscription tab and enter the details:

   • Subscription Name: CLIENT_VENDOR_REQTEMPLATE. [ Same as Manifest Name.]

   • Manifest Name: CLIENT_VENDOR_REQTEMPLATE. [ Same as Subscription Name.]

   • Select Schema: HRXML 2.5 Common Service (Background Check, and so on).

   • Select req template: Select the req template for the integration. [ One Req per Subscription.]

   • Custom candidate form for vendor results: You might need multiple forms if your vendor uses separate subscriptions for background and drug, or if you use multiple vendors. For more information, see Data Field Configuration.

   • Notes: [ Optional; Version or History Notes].

   • Export: Code or Description. [ Vendor to specify].

   • UTF type: N/A. [ Preset].

   • Client message: Display response message (default) or Display vendor/host configured m essage. Vendor to specify. If the vendor does not specify the selection, select Display response message.

   • Email error notification: None (default and recommended setting); Default email (System Admin); Custom email. [ Option to receive an email on error].

   • Error notification additional recipients: System Users. [ Option to add more system users to receive an email on error].

   • 2xO Onboarding: N/A

   • Additional XSLT formatting: N/A

   • Order Details Link Use Logged in User ID: Check box. [ This should be checked for users to access the Results Link in the Results Form.]

   • Export Country ISO Codes: Default; 2 Character ISO; 3 Character ISO. [ Vendor to specify].

   • Export State 2 Character ISO Codes: [ Vendor to specify]

   • HR Status: Select the HR Statuses that triggers the export.

   • Common Service Integration Type (Background Check, etc.): 1 step or 2-step. [ Depends on the Integration type available and wanted].

7. Select the Subscriber tab and enter the following details:

   • Select Vendor: List available of Common Service Background Check and Video Interviewing Vendors.

   • All Security & Transmission properties: N/A.

   • All Authentication properties: [ Vendor to specify].

8. Select the Mapping tab. The mapping fields information is provided by a vendor.

   • Select export fields: Opens a window to select the fields from one or more of: candidate forms, candidate profile, Talent record, Req Standard, Req Custom, and User Profile fields to be included in the subscription to the vendor.

     • Talent Record fields found as [Candidate info].

     • Talent Record State/Region/Province listed as [Candidate info] Location.

     • [User] fields pertain to the User initiating the transaction by using an HR Status update.

     • Document Sub Form (Offer Acceptance Form) fields are not available for mapping.

     • Select Submit. The screen refreshes to show the list of fields.

   • Include Education? and Include Experience?: Maps the Talent Record Standard Education and Experience fields to the vendor pre-mapped to the corresponding BGCs

     • All sends all supplied Education or Experience fields.

     • Most recent sends only the Education or Experience fields that are marked as most recent.

     • Selection of these Standard fields replace any manually mapped Education or Experience fields.

   • Select Map to map a field. The XML schema-mapping window opens.

     • Map all fields according to the vendor details and the mapping document for the vendor.

     • Mapped fields change color when mapped.

     • All fields should be mapped before saving.

     • BGC## in green is the field being edited

     • BGC## in gray have been mapped to another field and are not available for selection

     • BGC## in black have not been mapped

     • Hover over mapped fields to see the field that is mapped to that BCG number.

       

   • Select Add custom value to add custom tags or values. Any specific custom-mapping details are provided by the vendor. Insert the value and select map. Typically, custom values are mapped to the [ <ns:ClientReferences>] section.

     

9. After all Subscription, Subscriber and Mapping information is complete, select Save as active to make immediately available.

   1. After saving, warning message about Disabling SSL certification validation might appear. The SSL certificate validation settings for Common Service Integrations are pre-set and not editable by using the screens. This notification can be ignored by selecting Yes.

10. If additional subscriptions are needed for additional req templates, select Save as New Subscription. Update the subscription and manifest name to reflect the additional req template and select the appropriate req template.

    

Additional Optional Configurations

Rules Automation Manager (RAM) triggers.

1. Configure any RAM triggers that update the candidate to the HR status that triggers the integration for 1 step integrations.

2. Configure any RAM triggers to take further action based on the results of the integration. For more information, see Common RAM examples.

Test the Integration

After the vendor has completed their configuration, test the integration. Infinite recommends running several tests for each req template with varying packages and results.

Move to Production

Any configurations that are completed need to be manually moved to production.

Background Check Common Services For Generic Vendors

Background Check Common Services for Generic Vendors

For more information on the processes on this page, including project scoping, contact your Infinite Representative.

Introduction

This document serves as a guide for integrating with the Background Check Common Service (BG-CS). The BG-CS uses a common schema to interact with Background Check Service Vendors and ATS (Infinite Talent Applications). Therefore, BG-CS merely acts as a router or conduit between ATS and Vendor systems. The BG-CS interface is the Canonical Data Model for Background Checks. This includes data interactions for procurement and fulfillment of screening services. The terms Screening Service, Background Check Service, and BG-CS are used interchangeably and all refer to the Background Check Common Service.

The integration schema is based on the HR-XML/JSON (2.5) recommendation but includes a few Infinite-specific changes. The integration protocol is based on https post.

For the purposes of the document, the Background Check Vendors who integrate with Background Check Common Service are referred to as Vendors, Background Check Common Service Consumers (‘Infinite Talent Applications’) as ATS, and the Background Check Common Service as BG-CS.

Versioning

HR-XML/JSON is an evolving standard; as such not all operation schemas are available, for example, Get link request to Vendor’s website (Get Vendor URL). Infinite provides schema for this type of cases. This interface specification must also be a living standard within Infinite, and adhere to versioning standards to ensure flexibility and completeness, while protecting any existing implementations from change and being able to support as many integrations as required. Furthermore, future versions of BG-CS should update this document rather than create a new document detailing the interface.

Integration Schema

The Integration Schema defines the data that is required for communication with the BG-CS. This includes Order Entry, Order Modification, Order Updates, Order Response, and Order Viewing. These schemas are same as HR-XML/JSON 2.5 except a few variations, and all the types that were in different namespaces are flattened into one namespace. These schemas also include types that are not available in HR-XML/JSON 2.5. For example, Type for Get Vendor URL. All the types (HR-XML/JSON 2.5 and Custom) are defined under the namespace of “http://kenexa.com/Common/Screenings/Service/2.0”.

System Overview

Background Check Common Service integration illustration with Vendors and ATS by using HR-XML 2.5 and https standards.

Below is the illustration of Background Check Common Service integration with Vendors and ATS using JSON and https standards.

The Background Check Common Service Architecture is based on the premise that the BG-CS ATS is able to integrate with several Vendors without needing changes per Vendor. The new Vendor integration is done with zero development effort. The changes are limited to adding new Vendor configurations at BG-CS and ATS systems. This goal is achieved with the power of data abstraction that is provided by HR-XML. As illustrated in the above diagram BG-CS integration can be categorized into the following three operations:

1. Create background check request.

2. Background Reports (Accept status or result from Vendor).

3. Get Vendor URL (Get link request to Vendor website).

Vendor accepts both CreateBackgroundCheck and GetVendorUrl requests from a single URL because BG-CS sends both XML requests to the same URL.

1. Create Background Check

Create Background Check can be done in following two possible integration modes that are further detailed below:

1. One-step

2. Two-step

a. One-step Integration

The One-Step integration mode is one where there is no interaction of the ATS with the Vendor’s website. The request is transparently relayed from the ATS to the Vendor, and messages from the Vendor back to the ATS. This option is available by populating the packages within the Infinite Talent Applications, along with identifying and capturing the required field information. This is available for Vendors as their abilities permit.

The following is an overview of the standard feature set involved in One-Step integration (dependent on vendor capabilities).

• List of available packages shown within ATS

• Association of packages with jobs in ATS – at job code level or specific job

• Request background check through ATS for given candidate (that is, set HR Status or Activity)

• Request that satisfies data requirements that are automatically submitted to the vendor in the background.

b. Two-step Integration

This is the simplest form of integration that involves the ATS posting all information to the BG-CS. The BG-CS relays this information in the format or protocol specific to the Vendor. The ATS is returned a URL that redirects the user to the Vendor website where package selection and related data entry can be completed previous to submitting the order. After the order is submitted, the Vendor responds to the BG-CS with an Order Submission message and later, Order Completion information. This is transformed to the BG-CS schema and relayed to the ATS.

The following is an overview of the standard feature set involved in Two-Step integration (dependent on vendor capabilities).

• Request background check through ATS for given candidate (that is, set HR Status or Activity)

• Automatic authentication into vendor user interface

• Data transfer of available candidate information from ATS (might require mapping)

• Selection of packages or screenings, input of additional required fields, and submittal of request through vendor user interface

In both the modes, a create background check request is sent to Vendor system. The create background check request is a request for a background check order to the Vendor’s fulfillment system. It contains candidate and other important order information. A request becomes an order after the Vendor receives, accepts, and assigns it an order number. This is acknowledged back to the BG-CS. The request uses a push model for communication to and from the BG-CS.

A background check consists of one or more screenings. A screening is a particular type of search or verification procedure that is conducted as part of a background check. For example, a background check could include screenings of Criminal Check, Motor Vehicle Record Search, Education Verification, Employment Verification etc.

The steps that are involved in submitting a One-Step order are as follows.

1. Create background check request – BG-CS maps and sends this to the Vendor. BG-CS returns an Acknowledge message to the ATS with a transaction number.

2. Request goes into a load-balancing queue. Request is then routed to Vendor.

3. Vendor acknowledges receipt of the request, and assign an order number if request meets data requirements.

4. BG-CS receives the order submitted response, packages it into the BackgroundReports message, and posts asynchronously to the ATS.

5. ATS handles the message and updates the order status and details.

The steps that are involved in submitting a Two-Step order are as follows.

1. Create background check request – BG-CS receives this request and sends to the Vendor. BG-CS returns an Acknowledge message to the ATS with a redirect URL.

2. The user is navigated to the Vendor website, where the order entry is completed and submitted.

3. BG-CS receives the order submitted response and packages into the BackgroundReports message and posts asynchronously to the ATS Service.

4. ATS handles the message and updates the order status and details.

Important Note For new Vendor integration, a Vendor-specific configuration is required to set up both at BG-CS and ATS. Also, for One-Step integrations, additional configuration such as package information is required to set up.

Background Check is represented by the BackgroundCheck element, which is the parent element for all background check requests. This includes information that is related to authentication (account, user id, or password), candidate demographic information (Name, SSN, and Address), Candidate History (Past addresses, Education details, Experience details, etc.) and other screening-specific fields. If a package is specified in a One-Step request (a package is usually composed of more than one screening) then the package would need all data that is required to fulfill all screenings that are requested within the package before the package is marked complete. An alternative mechanism employed by some Vendors is to allow an email to be sent to the candidate requesting the candidate to complete missing information. In the case of most Vendors, for a Two-Step process, the package is not a required field. This allows the ATS to gather whatever information is available for a candidate, and allow the user to select the packages from the Vendor website, which may or might not use the information that was sent over. This provides flexibility on the completeness of required data from a package composition perspective.

Once an order is submitted (all data is provided to the Vendor, and the order submit action is complete), the Vendor responds with an Acknowledgement to confirm that the order has been submitted. This confirmation usually includes details about the order including the screenings that are selected. This can be used by the ATS to update information that is related to the order such as order status.

The following sections include information on the XML schema to be used for a request. An XML sample is available on request.

BackgroundCheck XML schema

Request sent to Vendor XML

<BackgroundCheck xmlns="http://kenexa.com/Common/Screenings/Service/2.0" userId="GB-CS user ID" password="BG-CS password" 
account="GB-CS account for vendor"><!-- Authenticating credentials --> <BackgroundSearchPackage><ProcessingInformation> 
<AccessCredential type="vendorid">ATS provided value</AccessCredential> <AccessCredential type="productid">ATS provided value</AccessCredential> 
 <AccessCredential type="operationmode">ATS provided value</AccessCredential> <!-- UserName can be a shared username for multiple users,
 or mapped to user employee ID or email address from ATS --> <AccessCredential type="UserName">Vendor provided value</AccessCredential>  
<AccessCredential type="Account">Vendor provided value</AccessCredential>  <AccessCredential type="Password">Optional (Vendor provided value) 
</AccessCredential> </ProcessingInformation><ReferenceId> <IdValue name="UniqueKey">ATS provided value (Unique value - Identifies order submission)
</IdValue><IdValue name="Token">BG-CS Provided value (a BG-CS internal unique key, can be ignored by vendor)</IdValue></ReferenceId> <ClientContact> 
 <ContactMethod><Telephone><FormattedNumber> ATS provided value </FormattedNumber> <Extension> ATS provided value </Extension> </Telephone> <Mobile>
 <FormattedNumber> ATS provided value </FormattedNumber> <Extension> ATS provided value </Extension> </Mobile> <Fax>  <FormattedNumber> 
ATS provided value </FormattedNumber> <Extension> ATS provided value </Extension> </Fax><InternetEmailAddress> ATS provided value </InternetEmailAddress>
</ContactMethod> </ClientContact><PersonalData> <PersonName type="subject"> <GivenName> ATS provided value </GivenName><MiddleName> ATS provided value 
</MiddleName> <FamilyName> ATS provided value </FamilyName><LegalName> ATS provided value </LegalName> </PersonName> <!-- Multiple instances: -->  
<PersonName type="alias"><GivenName> ATS provided value </GivenName> <MiddleName> ATS provided value </MiddleName> <FamilyName> ATS provided value 
</FamilyName><LegalName> ATS provided value </LegalName> </PersonName><!-- Multiple instances: --> <PostalAddress type="current" validFrom=" ATS provided value yyyy-mm-dd" 
validTo=" ATS provided value yyyy-mm-dd"><CountryCode> ATS provided value </CountryCode> <PostalCode> ATS provided value </PostalCode>
<Region> ATS provided value </Region> <Municipality> ATS provided value </Municipality><DeliveryAddress> <AddressLine> ATS provided value </AddressLine>
<AddressLine> ATS provided value </AddressLine> <Unit> ATS provided value </Unit> </DeliveryAddress> </PostalAddress> <!-- Multiple instances: -->  
<PostalAddress type="prior" validFrom=" ATS provided value yyyy-mm-dd" validTo=" ATS provided value yyyy-mm-dd"><CountryCode> ATS provided value 
</CountryCode> <PostalCode> ATS provided value </PostalCode> <Region> ATS provided value </Region> <Municipality> ATS provided value </Municipality>
<DeliveryAddress> <AddressLine> ATS provided value </AddressLine> <AddressLine> ATS provided value </AddressLine><Unit> ATS provided value </Unit>
</DeliveryAddress>  </PostalAddress> <!-- Multiple instances: --> <ContactMethod><Telephone><FormattedNumber> ATS provided value </FormattedNumber>  
<Extension> ATS provided value </Extension></Telephone> <Mobile> <FormattedNumber> ATS provided value </FormattedNumber><Extension> ATS provided value 
</Extension> </Mobile><Fax><FormattedNumber> ATS provided value </FormattedNumber><Extension> ATS provided value </Extension> </Fax> <InternetEmailAddress>
 ATS provided value </InternetEmailAddress> </ContactMethod><DemographicDetail><!-- Multiple instances: --> <GovernmentId issuingAuthority="SSN"> ATS 
provided value </GovernmentId><DateOfBirth> ATS provided value yyyy-mm-dd </DateOfBirth> <GenderCode> ATS provided value </GenderCode><Race> ATS provided
 value </Race></DemographicDetail></PersonalData><Screenings><PackageId><IdValue>Vendor provided value</IdValue></PackageId><ClientReferences>
<!-- Multiple instances: --><!--ClientReferences/IdValue can contain custom fields required by vendor, limit of 12 available --><IdValue name="Vendor
 provided value">Vendor provided value</IdValue></ClientReferences><SupportingDocumentation><Documentation><Text> ATS provided value </Text>
<InternetWebAddress> ATS provided value</InternetWebAddress></Documentation></SupportingDocumentation><UserArea><PositionAppliedFor> ATS provided value
 </PositionAppliedFor></UserArea><CopyToApplicant> ATS provided value </CopyToApplicant><!-- Multiple instances: --><Screening type="education">
<SearchEducation><EducationHistory><SchoolOrInstitution schoolType=" ATS provided value"><SchoolName> ATS provided value </SchoolName><PostalAddress>
<CountryCode> ATS provided value </CountryCode><Region> ATS provided value </Region><Municipality> ATS provided value </Municipality></PostalAddress>
<Degree degreeType=" ATS provided value"><DegreeName> ATS provided value </DegreeName><DegreeDate><StringDate> ATS provided value yyyy-mm-dd 
</StringDate></DegreeDate><DatesOfAttendance><StartDate><StringDate> ATS provided value </StringDate></StartDate><EndDate><StringDate> ATS provided 
value yyyy-mm-dd </StringDate></EndDate></DatesOfAttendance></Degree></SchoolOrInstitution></EducationHistory><AdditionalItems><Text> ATS provided value 
</Text></AdditionalItems></SearchEducation></Screening> <!-- Multiple instances: --><Screening type="employment"><!-- SearchEmployment  type can be
 either "current" or "prior" --><SearchEmployment type=" [current | prior]"><EmploymentHistory><EmployerOrg><EmployerOrgName> ATS provided value
</EmployerOrgName><PositionHistory><Title> ATS provided value </Title><Description> ATS provided value </Description><StartDate>
<StringDate> ATS provided value yyyy-mm-dd </StringDate></StartDate><EndDate><StringDate> ATS provided value yyyy-mm-dd </StringDate>
</EndDate><Compensation><EndingCompensation intervalType=" ATS provided value" currency=" ATS provided value"> ATS provided value </EndingCompensation>
</Compensation><Verification><ContactInfo><PersonName><FormattedName> ATS provided value </FormattedName></PersonName><ContactMethod>
<Telephone><FormattedNumber> ATS provided value </FormattedNumber><Extension> ATS provided value </Extension></Telephone><Mobile><FormattedNumber> 
ATS provided value </FormattedNumber><Extension> ATS provided value </Extension></Mobile><Fax><FormattedNumber> ATS provided value </FormattedNumber>
<Extension> ATS provided value </Extension></Fax><InternetEmailAddress> ATS provided value </InternetEmailAddress><Location> ATS provided value 
</Location><PostalAddress><CountryCode> ATS provided value </CountryCode><PostalCode> ATS provided value </PostalCode><Region> ATS provided value 
</Region><Municipality> ATS provided value </Municipality><DeliveryAddress><AddressLine> ATS provided value </AddressLine><AddressLine> ATS provided value
 </AddressLine></DeliveryAddress></PostalAddress></ContactMethod></ContactInfo><PermissionToContact> ATS provided value </PermissionToContact>
<ReasonForLeaving> ATS provided value </ReasonForLeaving></Verification></PositionHistory></EmployerOrg></EmploymentHistory><AdditionalItems><Text>
 ATS provided value </Text></AdditionalItems></SearchEmployment></Screening><!-- Multiple instances: --><Screening type="military"><SearchMilitary>
<MilitaryHistory><ServiceDetail branch=" ATS provided value"/></MilitaryHistory><AdditionalItems><Text> ATS provided value </Text></AdditionalItems>
</SearchMilitary></Screening><!-- Multiple instances: --><Screening type="criminal"><SearchCriminal><AdmittedCharges><CriminalCase><!-- Multiple instances:
 --><Charges><ChargeOrComplaint> ATS provided value </ChargeOrComplaint><ChargeTypeClassification> ATS provided value </ChargeTypeClassification></Charges>
</CriminalCase></AdmittedCharges><AdditionalItems><Text> ATS provided value </Text></AdditionalItems></SearchCriminal></Screening><!-- Multiple instances:
 --><Screening type="reference"><SearchReference><Contact><PersonName><FormattedName> ATS provided value </FormattedName></PersonName><ContactMethod>
<Telephone><FormattedNumber> ATS provided value </FormattedNumber><Extension> ATS provided value </Extension></Telephone><Mobile><FormattedNumber> ATS 
provided value </FormattedNumber><Extension> ATS provided value </Extension></Mobile><Fax><FormattedNumber> ATS provided value </FormattedNumber>
<Extension> ATS provided value </Extension></Fax><InternetEmailAddress> ATS provided value </InternetEmailAddress><PostalAddress><Region> ATS provided 
value </Region></PostalAddress></ContactMethod><YearsKnown> ATS provided value </YearsKnown></Contact><AdditionalItems><Text> ATS provided value </Text>
</AdditionalItems></SearchReference></Screening><!-- Multiple instances: --><Screening type="license"><SearchLicense><License><LicenseNumber> ATS provided
 value </LicenseNumber><LicensingAgency> ATS provided value </LicensingAgency><!--LicenseName can be used to indicate if it is Driver's license screening
 or professional certificate--><LicenseName> ATS provided value </LicenseName><LicenseDescription> ATS provided value </LicenseDescription><EffectiveDate>
<StartDate><StringDate> ATS provided value yyyy-mm-dd </StringDate></StartDate><EndDate><StringDate> ATS provided value yyyy-mm-dd </StringDate></EndDate>
</EffectiveDate></License><AdditionalItems><Text> ATS provided value </Text></AdditionalItems></SearchLicense></Screening><!-- Multiple instances: -->
<Screening type="drug"><SearchDrugs><SpecimenIdNumber><IdValue> ATS provided value </IdValue></SpecimenIdNumber><AdditionalItems><Text> ATS provided value
 </Text></AdditionalItems></SearchDrugs></Screening></Screenings>  </BackgroundSearchPackage>  </BackgroundCheck>  

Request sent to Vendor JSON

{ "BackgroundCheck": { "BackgroundSearchPackage": { "ProcessingInformation": { "AccessCredential": [ {
    "type": "vendorid", "value": "ATS provided value" }, { "type": "productid", "value": "ATS provided value" }, { "type": "operationmode", "value": "ATS
    provided value" }, { "type": "UserName", "value": "Vendor provided value" }, { "type": "Account", "value": "Vendor provided value" }, { "type": "Password",
    "value": "Optional (Vendor provided value)" } ] }, "ReferenceId": { "IdValue": [ { "name": "UniqueKey", "value": "ATS provided value (Unique value -
    Identifies order submission)" }, { "name": "Token", "value": "BG-CS Provided value (a BG-CS internal unique key, can be ignored by vendor)" } ] },
    "ClientContact": { "ContactMethod": { "Telephone": { "FormattedNumber": "ATS provided value", "Extension": "ATS provided value" }, "Mobile": {
    "FormattedNumber": "ATS provided value", "Extension": "ATS provided value" }, "Fax": { "FormattedNumber": "ATS provided value", "Extension": "ATS provided
    value" }, "InternetEmailAddress": "ATS provided value" } }, "PersonalData": { "PersonName": [ { "GivenName": "ATS provided value", "MiddleName": "ATS
    provided value", "FamilyName": "ATS provided value", "LegalName": "ATS provided value", "type": "subject" }, { "GivenName": "ATS provided value",
    "MiddleName": "ATS provided value", "FamilyName": "ATS provided value", "LegalName": "ATS provided value", "type": "alias" } ], "PostalAddress": [ {
    "CountryCode": "ATS provided value", "PostalCode": "ATS provided value", "Region": "ATS provided value", "Municipality": "ATS provided value",
    "DeliveryAddress": { "AddressLine": [ "ATS provided value", "ATS provided value" ], "Unit": "ATS provided value" }, "type": "current", "validFrom": " ATS
    provided value yyyy-mm-dd", "validTo": " ATS provided value yyyy-mm-dd " }, { "CountryCode": "ATS provided value", "PostalCode": "ATS provided value",
    "Region": "ATS provided value", "Municipality": "ATS provided value", "DeliveryAddress": { "AddressLine": [ "ATS provided value", "ATS provided value" ],
    "Unit": "ATS provided value" }, "type": "prior", "validFrom": " ATS provided value yyyy-mm-dd ", "validTo": " ATS provided value yyyy-mm-dd " } ],
    "ContactMethod": { "Telephone": { "FormattedNumber": "ATS provided value", "Extension": "ATS provided value" }, "Mobile": { "FormattedNumber": "ATS provided
    value", "Extension": "ATS provided value" }, "Fax": { "FormattedNumber": "ATS provided value", "Extension": "ATS provided value" }, "InternetEmailAddress":
    "ATS provided value" }, "DemographicDetail": { "GovernmentId": { "issuingAuthority": "SSN", "value": "ATS provided value" }, "DateOfBirth": "ATS provided
    value yyyy-mm-dd", "GenderCode": "ATS provided value", "Race": "ATS provided value" } }, "Screenings": { "PackageId": { "IdValue": "Vendor provided value"
    }, "ClientReferences": { "IdValue": { "name": "Vendor provided value", "value": "Vendor provided value" } }, "SupportingDocumentation": { "Documentation": {
    "value": "ATS provided value", "InternetWebAddress": "ATS provided value" } }, "UserArea": { "PositionAppliedFor": "ATS provided value" },
    "CopyToApplicant": "ATS provided value", "Screening": [ { "SearchEducation": { "EducationHistory": { "SchoolOrInstitution": { "SchoolName": "ATS provided
    value", "PostalAddress": { "CountryCode": "ATS provided value", "Region": "ATS provided value", "Municipality": "ATS provided value" }, "Degree": {
    "DegreeName": "ATS provided value", "DegreeDate": { "StringDate": "ATS provided value yyyy-mm-dd" }, "DatesOfAttendance": { "StartDate": { "StringDate":
    "ATS provided value" }, "EndDate": { "StringDate": "ATS provided value yyyy-mm-dd" } }, "degreeType": " ATS provided value " }, "schoolType": " ATS provided
    value " } }, "AdditionalItems": { "value": "ATS provided value" } }, "type": "education" }, { "SearchEmployment": { "EmploymentHistory": { "EmployerOrg": {
    "EmployerOrgName": "ATS provided value", "PositionHistory": { "Title": "ATS provided value", "Description": "ATS provided value", "StartDate": {
    "StringDate": "ATS provided value yyyy-mm-dd" }, "EndDate": { "StringDate": "ATS provided value yyyy-mm-dd" }, "Compensation": { "EndingCompensation": {
    "intervalType": " ATS provided value ", "currency": " ATS provided value ", "value": "ATS provided value" } }, "Verification": { "ContactInfo": {
    "PersonName": { "FormattedName": "ATS provided value" }, "ContactMethod": { "Telephone": { "FormattedNumber": "ATS provided value", "Extension": "ATS
    provided value" }, "Mobile": { "FormattedNumber": "ATS provided value", "Extension": "ATS provided value" }, "Fax": { "FormattedNumber": "ATS provided
    value", "Extension": "ATS provided value" }, "InternetEmailAddress": "ATS provided value", "Location": "ATS provided value", "PostalAddress": {
    "CountryCode": "ATS provided value", "PostalCode": "ATS provided value", "Region": "ATS provided value", "Municipality": "ATS provided value",
    "DeliveryAddress": { "AddressLine": [ "ATS provided value", "ATS provided value" ] } } } }, "PermissionToContact": "ATS provided value", "ReasonForLeaving":
    "ATS provided value" } } } }, "AdditionalItems": { "value": "ATS provided value" }, "type": " [current | prior] " }, "type": "employment" }, {
    "SearchMilitary": { "MilitaryHistory": { "ServiceDetail": { "branch": " ATS provided value " } }, "AdditionalItems": { "value": "ATS provided value" } },
    "type": "military" }, { "SearchCriminal": { "AdmittedCharges": { "CriminalCase": { "Charges": { "ChargeOrComplaint": "ATS provided value",
    "ChargeTypeClassification": "ATS provided value" } } }, "AdditionalItems": { "value": "ATS provided value" } }, "type": "criminal" }, { "SearchReference": {
    "Contact": { "PersonName": { "FormattedName": "ATS provided value" }, "ContactMethod": { "Telephone": { "FormattedNumber": "ATS provided value",
    "Extension": "ATS provided value" }, "Mobile": { "FormattedNumber": "ATS provided value", "Extension": "ATS provided value" }, "Fax": { "FormattedNumber":
    "ATS provided value", "Extension": "ATS provided value" }, "InternetEmailAddress": "ATS provided value", "PostalAddress": { "Region": "ATS provided value" }
    }, "YearsKnown": "ATS provided value" }, "AdditionalItems": { "value": "ATS provided value" } }, "type": "reference" }, { "SearchLicense": { "License": {
    "LicenseNumber": "ATS provided value", "LicensingAgency": "ATS provided value", "LicenseName": "ATS provided value", "LicenseDescription": "ATS provided
    value", "EffectiveDate": { "StartDate": { "StringDate": "ATS provided value yyyy-mm-dd" }, "EndDate": { "StringDate": "ATS provided value yyyy-mm-dd" } } },
    "AdditionalItems": { "value": "ATS provided value" } }, "type": "license" }, { "SearchDrugs": { "SpecimenIdNumber": { "IdValue": "ATS provided value" },
    "AdditionalItems": { "value": "ATS provided value" } }, "type": "drug" } ] } }, "userId": "GB-CS user ID", "password": "BG-CS password", "account": "GB-CS
    account for vendor" }}

Response expected from Vendor XML

For one-step operation:

<ApplicationAcknowledgement xmlns="http://kenexa.com/Common/Screenings/Service/2.0"> <PayloadResponseSummary> 
<ProcessingTimestamp description="(optional)">Vendor provided value</ProcessingTimestamp> <AcknowledgementCreationTimestamp> Vendor provided value 
</AcknowledgementCreationTimestamp> </PayloadResponseSummary> <PayloadDisposition> <EntityDisposition> <EntityInstanceXPath>(optional)
</EntityInstanceXPath> <EntityIdentifier> <IdValue name= “BackgroundCheckOrderNumber"> (vendor order ID) </IdValue> </EntityIdentifier> 
<EntityNoException> true/false </EntityNoException> <EntityException> <Exception> <ExceptionIdentifier>(optional)</ExceptionIdentifier> 
<ExceptionSeverity> (optional) </ExceptionSeverity> <ExceptionMessage> (required)</ExceptionMessage> </Exception> </EntityException> </EntityDisposition> </PayloadDisposition> </ApplicationAcknowledgement>

For two-step operation:

<ApplicationAcknowledgement xmlns="http://kenexa.com/Common/Screenings/Service/2.0"> <PayloadResponseSummary> <ProcessingTimestamp description="Vendor
 provided value">Vendor provided value</ProcessingTimestamp> <AcknowledgementCreationTimestamp> Vendor provided value </AcknowledgementCreationTimestamp>
 </PayloadResponseSummary> <PayloadDisposition> <EntityDisposition> <EntityInstanceXPath> Vendor provided value </EntityInstanceXPath> <EntityIdentifier>
 <IdValue name=" BackgroundCheckRedirectURL"> Vendor provided value </IdValue> </EntityIdentifier> <EntityNoException> Vendor provided value (true/false)
 </EntityNoException> <EntityException> <Exception> <ExceptionIdentifier> Vendor provided value </ExceptionIdentifier> <ExceptionSeverity> Vendor provided
 value </ExceptionSeverity> <ExceptionMessage> Vendor provided value </ExceptionMessage> </Exception> </EntityException> </EntityDisposition> 
</PayloadDisposition> </ApplicationAcknowledgement>

Response expected from Vendor JSON

For one-step operation:

{ "ApplicationAcknowledgement": { "PayloadResponseSummary": { "ProcessingTimestamp": { "description": "(optional)", "value": "Vendor provided 
value" }, "AcknowledgementCreationTimestamp": "Vendor provided value" }, "PayloadDisposition": { "EntityDisposition": { "EntityInstanceXPath": 
"(optional)", "EntityIdentifier": { "IdValue": { "name": "BackgroundCheckOrderNumber", "value": "(vendor order ID)" } }, "EntityNoException": 
"true/false", "EntityException": { "Exception": { "ExceptionIdentifier": "(optional)", "ExceptionSeverity": "(optional)", "ExceptionMessage": 
"(required)" } } } } }}

For two-step operation:

{ "ApplicationAcknowledgement": { "PayloadResponseSummary": { "ProcessingTimestamp": { "description": "Vendor provided value", "value": 
"Vendor provided value" }, "AcknowledgementCreationTimestamp": "Vendor provided value" }, "PayloadDisposition": { "EntityDisposition":
 { "EntityInstanceXPath": "Vendor provided value", "EntityIdentifier": { "IdValue": { "name": " BackgroundCheckRedirectURL ", "value": 
"Vendor provided value" } }, "EntityNoException": "Vendor provided value (true/false)", "EntityException": { "Exception": { "ExceptionIdentifier":
 "Vendor provided value", "ExceptionSeverity": "Vendor provided value", "ExceptionMessage": "Vendor provided value" } } } } }}

2. Background Reports (Accept Background Check Status and Results from Vendor)

After the background check is completed by the Vendor, results are sent back in the Background Reports Message. This is received asynchronously from the request. Background Reports consist of screening results of one or more screenings that are requested in the Background Check Request.

The following sections include information on the XML/JSON schema to be used in the reports. An entire XML/JSON sample is available on request.

Request from Vendor XML

<BackgroundReports xmlns="http://kenexa.com/Common/Screenings/Service/2.0" account="" userId=" (optional)"> <BackgroundReportPackage type=" 
(optional)"> <ProcessingInformation> <AccessCredential type="Vendor"> (Vendor Name, required) </AccessCredential> </ProcessingInformation> 
<ProviderReferenceId> <IdValue> (required, vendor order id, uniquely identifies order) </IdValue> </ProviderReferenceId> <ClientReferenceId> 
<IdValue> (Rreuired, this is the same UniqueKey sent from the backgroundCheck Order)</IdValue> </ClientReferenceId> <PackageId> <IdValue>
 (optional) </IdValue> </PackageId> <ScreeningStatus> <OrderStatus> (required) </OrderStatus> <ResultStatus> (optional) </ResultStatus> <Score>
 (optional) </Score> <DateOrderReceived> (required) </DateOrderReceived> </ScreeningStatus> <ScreeningsSummary> <PersonalData> <PersonName> 
<GivenName> (required) </GivenName> <MiddleName> (needed if available) </MiddleName> <FamilyName> (required) </FamilyName> </PersonName> 
</PersonalData> <ClientReferences> <IdValue name=" (optional)"> (optional) </IdValue> </ClientReferences> </ScreeningsSummary> <Screenings> 
<!-- Multiple instances: --> <Screening qualifier=" (optional)" type=" (optional)"> <ScreeningStatus> <OrderStatus> (optional) </OrderStatus>
 <ResultStatus> (optional) </ResultStatus> </ScreeningStatus> </Screening> </Screenings> </BackgroundReportPackage> </BackgroundReports>

Request from Vendor JSON

{ "BackgroundReports": { "BackgroundReportPackage": { "ProcessingInformation": { "AccessCredential": { "type": "Vendor", "value": "(Vendor Name,
 required)" } }, "ProviderReferenceId": { "IdValue": "(required, vendor order id, uniquely identifies order)" }, "ClientReferenceId": { "IdValue":
 "(Rreuired, this is the same UniqueKey sent from the backgroundCheck Order)" }, "PackageId": { "IdValue": "(optional)" }, "ScreeningStatus": 
{ "OrderStatus": "(required)", "ResultStatus": "(optional)", "Score": "(optional)", "DateOrderReceived": "(required)" }, "ScreeningsSummary": 
{ "PersonalData": { "PersonName": { "GivenName": "(required)", "MiddleName": "(needed if available)", "FamilyName": "(required)" } }, 
"ClientReferences": { "IdValue": { "name": " (optional) ", "value": "(optional)" } } }, "Screenings": { "Screening": { "ScreeningStatus": 
{ "OrderStatus": "(optional)", "ResultStatus": "(optional)" }, "qualifier": " (optional) ", "type": " (optional) " } }, "type": " (optional) " },
 "account": "", "userId": " (optional) " }}

Response sent to Vendor XML (this is BrassRing proprietary)

<BackgroundReportResponse><Status> (success / fail) </Status>  <Description> (error message if fail) </Description>  </BackgroundReportResponse> 

Response sent to Vendor JSON (this is BrassRing proprietary)

{    "BackgroundReportResponse": {  "Status": "(success / fail)", "Description": "(error message if fail)"    }}

Post Background Check Results to ATS

The background check results are asynchronously posted from the BG-CS to the ATS. This implies that the ATS must implement a web service or a web page that handles the results posted to it. The ATS, after receiving the results, must post an Acknowledge message back to the BG-CS to confirm receipt of the results.

3. Get Vendor URL (Get link request to Vendor website)

ATS can use another BG-CS operation called Get Vendor URL, which returns the appropriate URL for viewing order details within the Vendor system. Validation occurs by BG-CS to authenticate ATS, and returns a redirect URL based on the Vendor support for one of the two options.

The returned URL from BG-CS is, depending on Vendor support:

1. Configured Hard link that requires a subsequent login by the user in the Vendor system.

2. Automatic authentication link that authenticates the user and automatically redirects to the order details page in Vendor system. This can be achieved when BG-CS route ATS request to Vendor supported GetVendorURL operation. Upon triggering this operation vendor generates an expiring link and sending the same in response.

Request sent to Vendor XML

<VendorUrlRequest xmlns="http://kenexa.com/Common/Screenings/Service/2.0" type="view" vendor="BG-CS provided value" productId="BG-CS provided 
value" account="Vendor provided value" userId="Vendor provided value" password="Vendor provided value"> <ProviderReferenceId> Vendor provided value 
(vendor background order number) </ProviderReferenceId> <AccountCredential> <Account> (client ordering account) </Account> <UserName> (client user
 name) </UserName> <!--password and token will not be provided --> <Password/> <Token/> </AccountCredential> </VendorUrlRequest>

Request sent to Vendor JSON

{ "VendorUrlRequest": { "ProviderReferenceId": "Vendor provided value (vendor background order number)", "AccountCredential": { "Account": "(client
 ordering account)", "UserName": "(client user name)", "Password": "", "Token": "" }, "type": "view", "vendor": "BG-CS provided value", "productId"
: "BG-CS provided value", "account": "Vendor provided value", "userId": "Vendor provided value", "password": "Vendor provided value" }}

Response from Vendor XML

<ApplicationAcknowledgement xmlns="http://kenexa.com/Common/Screenings/Service/2.0"> <PayloadResponseSummary> <ProcessingTimestamp description=
"Link Response"/> <AcknowledgementCreationTimestamp/> </PayloadResponseSummary> <PayloadDisposition> <EntityDisposition> <EntityInstanceXPath/> 
<EntityIdentifier> <IdValue name="Status">Complete</IdValue> <IdValue name="LinkURL"> Vendor provided value </IdValue> </EntityIdentifier> 
</EntityDisposition> </PayloadDisposition> </ApplicationAcknowledgement>

Response from Vendor JSON

{ "ApplicationAcknowledgement": { "PayloadResponseSummary": { "ProcessingTimestamp": { "description": "Link Response" }, 
"AcknowledgementCreationTimestamp": "" }, "PayloadDisposition": { "EntityDisposition": { "EntityInstanceXPath": "", "EntityIdentifier": 
{ "IdValue": [ { "name": "Status", "value": "Complete" }, { "name": "LinkURL", "value": "Vendor provided value" } ] } } } }}

A valid LinkURL should always be returned from the vendor even if the result is not ready. BrassRing ATS always follows the LinkURL to redirect users to the vendor’s web page. When the result is not ready, or the result cannot be displayed for some reason (that is, the user is not authorized to view the report), a meaningful message should be displayed.

Implementation Setup Information Needed from Vendor:

To start integration testing the following is needed from the Vendor:

1. Is this integration a one-step or two-step integration?

2. What communication protocol does this integration use? SOAP or pureXML through HTTP POST?

3. Infinite Talent Background Check Common Service system has systems in the US and EU with different endpoints. US clients are set up in BGCS US system and EU clients are set up in BGCS EU system. Which system is the vendor to integrate with? or both?

4. The vendor needs to complete the   mapping document  with the column highlighted (Required by Vendor), indicating Required (R), Optional (O), or Not used (N/A).

5. Provide us the URL (test environment) for sending requests to create   BackgroundCheck  order and request for   getVendorURL. This needs to be configured in the common service staging environment.

6. Provide us with the test account/username/password for both the integration account and the test client account. Infinite configures the staging common service environment for integration tests.

   Common Service Integration account XML:

   <BackgroundCheck account="" password="" userId="">

   Common Service Integration account JSON:

   "BackgroundCheck": {  "account": "",  "password": "","userId": ""    }

   Client Test Account XML:

   <BackgroundCheck> <BackgroundSearchPackage> <ProcessingInformation>  <AccessCredential type="Account"/>  <AccessCredential type="UserName"/> 
    <AccessCredential type="Password"/>  

   Client Test Account JSON:

   "BackgroundCheck": {   "BackgroundSearchPackage": {  "ProcessingInformation": {  "AccessCredential": [   {  "type": "Account"  },   
    {  "type": "UserName" }, {  "type": "Password" } } } }

7. If this is a one-step integration, then provide the PackageID they would use for testing.

8. For US and EU system integration, configure your system to send background results back to common service staging at:

   https://comsvc-stage.brassring.com/v2/BackgroundCheckService/BackgroundCheckResponse

9. After the test is complete, before the integration is certified, the setup information (2,3,4) for the production environment is needed. Also, configure your production system to point to our common service production URL:

   US: https://comsvc.brassring.com/v2/BackgroundCheckService/BackgroundCheckResponse

   EU: https://comsvc-eu.brassring.com/v2/BackgroundCheckService/BackgroundCheckResponse

Implementation Guidelines to vendor:

There is only one integration account per vendor as it is used to identify integration between BG-CS and a vendor. This integration account is configured in BG-CS.

There can be multiple client integration accounts configured in ATS system, each to identify a client integration that is configured to integrate with the background check vendor through BG-CS

When ATS sends a background check request to BG-CS, it only contains client integration account credentials. BG-CS then adds the BG-CS integration account information in the request before routing it to the vendor (ATS or the user does not have BG-CS integration account information).

For security reasons, the integration partner needs to verify both the BG-CS integration account and the client integration account.

For security reasons, the integration partner needs to verify both the BG-CS integration account and the client integration account.

Note:  Vendor should accept both CreateBackgroundCheck and GetVendorUrl  requests from a single URL because BG-CS sends both XML requests to the same URL.

• Schema files defined in Appendix B.

  • CommonServicesTypes.xsd – Vendor host endpoint by using this schema.

  • BackgroundReportTypes.xsd – Infinite host endpoint by using this schema

• Host an endpoint and possibly integrate it with existing system. There are the two ways to host endpoint:

  • Simple XML through HTTP endpoint: This accepts the xml packet as per the schemas in CommonServicesTypes.xsd. In this option, only Infinite schemas are used.

  • SOAP WebService endpoint: If this option is selected, then Vendor should use the wsdl that is provided in Appendix A. In this option, both Infinite schema and wsdl are used.

• Endpoint should support following two operations:

  • CreateBackgroundCheck – Receives request, generates order and ApplicationAcknowledgment as response.

  • GetVendorURL – Receives request, generate non-expiring auto login link and ApplicationAcknowledgment

• Vendors are free to choose their convenient platform and technology to do this.

• The endpoint should be supporting https xml post.

Integration with multiple data centers:

Currently common service system is available in two data centers - US data center and EU data center. Common service US data center is integrated with US ATS (BrassRing US) and common service EU data center is integrated with EU ATS (Brassring EU). If vendor needs to support both US and EU customers then it is suggested to also have two environments to integrate with our two systems. If for some reason vendor only has one system available then vendor needs to be able to post background result status back to the correct US or EU endopoints.

One way to tell if an order request was from US or EU data center is by referring to the productid field in the below XML document. Where it can contain the following values:

• KRBPROD - Kenexa Recruiter BrassRing Prod in US

• KRBPRODEU - Kenexa Recruiter BrassRing Prod in EU

• KRBSTG - Kenexa Recruiter BrassRing Staging in US

• KRBSTGEU - Kenexa Recruiter BrassRing Staging in EU

XML:

<BackgroundSearchPackage>  <ProcessingInformation><AccessCredential type="vendorid"> (The vendor ID) </AccessCredential> <AccessCredential 
type="productid"> [KRBPROD/KRBPRODEU/KRBSTG/KRBSTGEU] </AccessCredential>  

"BackgroundSearchPackage": { "ProcessingInformation": { "AccessCredential": [  { "type": "vendorid",  "value": "(The vendor ID)"  
 },   {   "type": "productid",  "value": "[KRBPROD/KRBPRODEU/KRBSTG/KRBSTGEU]"   }    ]    }}

Appendix A – WSDL

<?xml version="1.0" encoding="UTF-8"?>  <wsdl:definitions name="BackgroundCheckService" 
xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:messages="http://kenexa.com/Common/Screenings/Service/2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" 
targetNamespace="http://kenexa.com/Common/Screenings/Service/2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">  	
<wsdl:types> <xs:schema attributeFormDefault="qualified" elementFormDefault="qualified" 
targetNamespace="http://kenexa.com/Common/Screenings/Service/2.0"><xs:include schemaLocation="CommonServicesTypes.xsd"/>
</xs:schema></wsdl:types>  	<wsdl:message name="BackgroundCheckRequest"><wsdl:part element="messages:BackgroundCheck" 
name="BackgroundCheckRequest"/> </wsdl:message>  <wsdl:message name="Acknowledge"> <wsdl:part element="messages:ApplicationAcknowledgement" 
name="Acknowledge"/></wsdl:message> <wsdl:message name="VendorUrlRequest"><wsdl:part element="messages:VendorUrlRequest" name="VendorUrlRequest"/>
  	</wsdl:message> <wsdl:portType name="BackgroundCheckPort">  <wsdl:operation name="CreateBackgroundCheck">  		
<wsdl:input message="messages:BackgroundCheckRequest"/>  <wsdl:output message="messages:Acknowledge"/> </wsdl:operation>  	
	<wsdl:operation name="GetVendorUrl"> <wsdl:input message="messages:VendorUrlRequest"/>  		
<wsdl:output message="messages:Acknowledge"/> </wsdl:operation> </wsdl:portType><wsdl:binding name="BackgroundCheckBinding" 
type="messages:BackgroundCheckPort"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>  	
	<wsdl:operation name="CreateBackgroundCheck"> <soap:operation style="document" soapAction=""/> <wsdl:input>  
<soap:body use="literal"/> </wsdl:input> <wsdl:output><soap:body use="literal"/></wsdl:output> </wsdl:operation> <wsdl:operation name="GetVendorUrl">  
<soap:operation style="document" soapAction=""/> <wsdl:input> <soap:body use="literal"/> </wsdl:input><wsdl:output> <soap:body use="literal"/>  	
</wsdl:output> </wsdl:operation>  	</wsdl:binding>  	<wsdl:service name="BackgroundCheckService"><wsdl:port binding="messages:BackgroundCheckBinding" 
name="BackgroundCheckPort"><soap:address location="REPLACE_WITH_ACTUAL_URL"/></wsdl:port></wsdl:service></wsdl:definitions>  

Appendix B – Common Service XML Schemas

Get the following XSD’s from Infinite:

1. CommonServicesTypes.xsd – Types defined for implementing CreateBackgroundCheck and GetVendorURL operation.

2. BackgroundReportTypes.xsd – Infinite hosted results endpoint by using the types that are defined in this xsd.

COMMON SERVICE INTEGRATIONS: MAPPING DOCUMENTS

Abstract

Product: Workbench

Common Service Integrations: Mapping Documents

The mapping documents are used to help configure third-party vendor integrations with BrassRing. The documents describe the required and optional fields for third-party vendor integrations.

COMMON SERVICES - ASSESSMENTS

Abstract

Product:  Workbench

Common Services - Assessments

Assessments play a very important role in evaluating a candidate’s skills in the process of hiring. There are various organizations that provide comprehensive assessment solutions available in the market and BrassRing can integrate with any of them given that it is beneficial to the clients.

BrassRing has already integrated with various 3rd party assessment vendors. Clients can choose the assessment vendors that are available or they can request for adding a new vendor that they are interested in. BrassRing supports 3rd party vendor integration through our Common Service Assessment API. Vendors need to comply with API guidance, BrassRing engineering will set-up the integration and QA will test and certify the integration.

Click  HERE to review the Assessment-BrassRing Configuration Guide that covers:

• Client Settings

• Configuring the Assessment Vendor

• Banding and Batches

• Custom Req Fields and Candidate Forms

• User Type Privileges

• Talent Gateway Settings and Text Customizations

• RAM Triggers

• The BrassRing User Experience

Frequently Asked Questions

Integration Questions

• What is your primary method of integration (API)? Web Services, HTML, or other?  Web Services

• What triggers an API call?

  When recruiter clicks on send assessment. Assessment list will be requested.

  Request session call – click on assessment link in TG or Launch in BR.

  Result posting – as soon as the candidate completes.

• What happens during an API call?  Data gets exchanged.

• What data is sent between BrassRing and Vendor during an API call?  Predominantly Assessment details, Candidate, req details and results.

• How do the systems acknowledge that data has (or has not) been received?  Status is sent back as “Success” or not.

• What retry logic exists to ensure that API communications are successful? Vendor must retry to post assessment as soon as a failure status sent back.

• What if a candidate finishes the assessment in time but the results are not received by Brassring due to system issues until after that assessment time has expired? Assessments status shows as In-Progress, candidate may click on the link again. We recommend vendors to display a message when the assessment link s clicked that the assessment is complete and results are in process.

• When are e-mails sent to the candidate?  RAM can be configured to trigger automated communication upon HR Status update. RAM can be configured to auto update HR status based on Assessment Score.

• Can you explain what a session means to BrassRing in terms of a Assessment is being Requested? Session is the time limit given for each assessment.  The session starts as soon as the candidate clicks on the assessment URL and assessment launches.

• What is represented by the session ID? And what is the max length of this field?  A unique identifier for each session.

• Can you add a custom field to the Assessment form to be populated by the integration (coming from the vendor)?  No. Vendors can only use the standard fields on the form to send information in. If the vendor isn't using a field, they may be able to re-purpose it.

• What is represented by the session URL? Is that a stored URL link for the survey?  Session URL represents an individual Assessment which is not in final state). Every time a candidate clicks on the assessment to take, the candidate is redirected to the same session URL.

Candidate Questions

• Where will Candidates take assessments from?  Candidates can take assessments: Directly from TGs (All assessments are listed in Pending Assessment Page. OR Launch Assessment at the end of the application flow). Through e-links sent to e-mails or launched by recruiters on their screen.

Recruiter Questions

• We would like to send assessments to our candidates after the Recruiter has completed a phone interview NOT at the candidate application phase. Is this possible?  Yes possible, in three ways:

  1. Recruiter can run any assessments attached to the req(job) on demand from the candidate record.

  2. Recruiter can manually send email communication to the candidate after phone interview.

  3. RAM trigger can be set up to send out auto communication email to the candidate that contains link to take the assessment.

• Can assessment orders be initiated automatically based on a certain candidate status, initiated manually, or both?  If triggered manually, can recruiters order an assessment for a single candidate or a group of candidates? Yes, both. An assessment order request contains only one candidate.

• Does the Assessment Order Request (AOR) get sent to vendor when the candidate clicks within the workflow, or does the registration occur before the candidate reaches the relevant stage of the application? (I.e. are they clicking on a URL that instigates a registration or the actual vendor assessment URL?)  AOR sent only when candidate clicks the assessment link. Link from e-mail redirects to the assessment page in career portal which lists the pending assessments that are direct links to Vendor. Candidate can get to this page directly from career portal.

• Can the email be resent to the candidate? If this is the case would it be a new registration (I.e. separate link) or a resend of the original link?  e-mail can be resent manually; above answer explains the second step.

• If an e-mail is lost can a candidate still login to the ATS and access the hyper-link to take the assessment?  Yes.

• Is there the ability to set a time frame for completion of the VENDOR Assessments? (Link expiry)  Yes.

• Is this flexible for any assessment or does this need to be specially set-up per each type of assessment integrated?  Configurable.

• For a Sitting, do you store just the Overall Score, or the Detailed scores also? If Detailed scores also, is there a maximum number of fields available to house these scores (please state)?  Overall Score.

• Can scores be displayed in Candidate grids? (i.e. multiple candidate scores are available on a single page)  Configurable to display them from the assessment forms.

• If VENDOR  reposts a score to the ATS, will the score be added to the candidate record, or will there be a problem accepting a score for a candidate who has already completed? I.e. will the existing score need to be removed first before a new score is reposted?  No. Repost is not possible if there is an existing score. existing score need to be removed first before a new score is reposted

• Can equations be configured within the ATS that combine data including VENDOR scores to calculate derived scores like an overall fit score for example?  Yes. Banding such as recommended, not recommended with colour coding can be configured.

• Within BrassRing, are scores from assessments held against a candidate’s application for a specific role only, or if they apply for another role would the latest assessment results be stored against the old application too? Similarly, can old scores reports be transferred to a new role/requisition to mitigate the need for candidates to complete assessments more than once?  If the assessment id is same, scores will be copied over.

• If VENDOR reposted a large volume of scores at once, could this cause issues on the ATS side?  Repost is not possible in the standard integration. Client/Vendor can check with PSE through the client if this is possible via custom work.

• Can a candidate be sifted automatically and progressed into a new status by the ATS system automatically by evaluation of an SHL score or derived score? Are there limitations or specific fields used only?  Yes, with RAM.

• Can a second Assessment Request be triggered to SHL based on an evaluation of an SHL score?  Yes, with Assessment Hurdle Score within a Batch or with RAM for individual assessments outside batch.

• If there is more than one assessment tied to a Job Code, can the recruiter send one email communication with one link that provides the candidates access to all applicable assessments attached?  Yes, the email that is sent in the above 3 methods will have a link(s) all of which would take the candidate to a single page in Talent Gateway which will always list all applicable assessments associated with the job/candidate.

• If we send the assessments through a vendor, can the system flag to recruiters when the candidate has already completed an assessment?  Upon candidate completing an assessment, vendor would send results back to BrassRing that in turn creates candidate form in Brassring. So, recruiter can manually check for the existence of that candidate form or set up a RAM to send out notification email upon this candidate form creation.

• Can the recruiter add an ad-hoc assessment (aside from the ones that have been mapped to the Job Code)? Does the recruiter have the option to choose from a pick list of items?  Yes, this is possible using Run assessment feature in BrassRing.

Workbench User / Configuration Questions

• How do you find the assessment IDs in Workbench?  Go to Tools > Integrations > Assessments > List of assessments are available > Right-click and View Source to find the IDs.

• Assessment integration with 3rdparty, looking to set the lifespan of the assessments. For those that have passed the tests this is fine, they're setting all tests to the same lifespan. However for those that fail a test, they cannot retake until 4 months after they failed. Is this possible to setup? A candidate cannot retake assessment until the lifespan expires regardless of the assessment result (pass or fail). Clients need to set up parameters (with help from the Infinite Assessments team) that determine how long test results are valid. When these parameters are set up, an applicant who has completed assessments within the designated time frame will not have to retake the assessments for a different job requisition. Once an assessment is complete, candidate will not be allowed to retake unless the recruiter assigns the assessment to candidate for retake. Candidates can retake only those assessments that are assigned to them to retake. Recruiter sends the assessment e-link for a candidate to retake.

• Using assessments and allowing candidates to reapply: If a candidate withdraws before completing the assessment, and then reapplies within 7 days before the incomplete assessment of the original application has expired, will a new assessment initiate and remain open for the next 7 days?  If the Assessment ID is same, the assessment will launch from where the candidate has left-off previously for all future reqs with same assessment. If the assessment already expired, recruiter must manually give retake in this scenario.

• When in a talent record, one of the System Admin users can see/use the ’run assessment’ and ‘retake assessment’ options but, for the other System Admin user, these two options are greyed out. Is this likely to be associated with Permission settings within BrassRing, or within Assess?  This could be because of user privileges, check user settings in workbench.

• For clients that trigger an assessment to go out via a RAM trigger once an HR status is hit: Client wants to add a third assessment but they don't want it to go to the candidate until they hit a certain HR Status. The issue is that is already two other assessments that are being triggered at the time candidates apply. So, I am not sure there is an automated way to do that since they don't want to make any changes to the existing assessments. All positions are on the same TG.  Trigger assessment e-link based HR Status in RAM

• Identify what user type permission gives a person the ability to select 'Run Assessment'? Currently they can select 'Retake Assessment' but not 'Run.'  Please check user permissions in workbench, there is an option for ‘Run Assessment’. Refer to the configuration guide.

  1. Assessment – run: This privilege enables the user to manually run any assessment assigned to the apply requisition.

  2. Assessment – run optional assessments: This privilege enables the user to manually run any assessment that is not assigned to the requisition.

  3. Assessment – run retake: This privilege enables the user to manually run a previously completed assessment for a candidate to enable to candidate to retake the assessment.

• When candidate is kicked out or logged out of the assessment, they should not be stopped from going back to take the assessment later (WSI Assessment)?  Unless the assessment lifespan expires, candidate can continue with the assessment anytime. Some vendors may put a cap on number of sessions but is upon agreement with the customer. BrassRing does not limit this.

• Is the text around taking an assessment at the end of a responsive GQ can be edited?  Yes, the text can be configurable at text customization.

• How do you configure the KAS Assessment Form used in common service assessment integration to display additional dimension scores names and dimension scores?  See  here

• If you update the lifespan on an assessment, does it take effect on all reqs currently posted with that assessment attached or do you have to repost the req?  Lifespan can be configured at individual assessment level or at vendor level. If edited, it applies to all reqs with the assessment attached.

• Where can you update the Return Candidate URL for an assessment - Chemistry Group?  Support cannot update this URL, but engineering can.

• I am currently launching an assessment at the end of the application process. We are posting these jobs to both the External and Internal TG’s. We only want the External Candidates to take the Assessment, as the Internals already passed an assessment to be currently working for the company. So my question is this; can we attach the Assessment to the Req and only add it to the External TG?  This is possible to configure assessments to only External TGs. When posting a requisition, the user can select the batch to be presented on each of the gateways the Req is posted to. This provides flexibility to accommodate unique requirements for internal versus external candidates.

• Does the [assessment] token work for auto-launch on responsive TG/Responsive GQ?  The TG settings has text saying auto-launch not supported for responsive TG/GQ? Auto Launch is not supported for responsive.

• The KAS Assessment form(s) and the KAS Overall Results form will be deleted from a candidate's talent record immediately after a Retake Assessment function is initiated. This is true regardless of form multiples?  The talent record will still house the results of the assessment(s) taken under an "Assessment Completed" action but the "Form Added" action for these forms will be gone.

• I'm adding an Assessment manually in Workbench and am getting an error when trying to add an Assessment code/ID over 40 characters.  When manually adding an Assessment, the ID field has a 40 character limit. If the vendor creates the assessment with a sync process the character limit for the ID field is 100 characters.

• Can the assessment form be added manually by a user?  Assessment form is added by integration itself. But in the candidate talent record you will see the user details because the integration adds the user (first name, lastname) who has created the requisition.

INTEGRATIONS - AVATURE

Abstract

Product:  Workbench

Avature Integration

• To configure the Avature integration, the Client Setting Integration Candidate Relationship Management (CRM) → Avature must be enabled. Only Infinite Representatives can enable Client Settings. Contact your organizations Infinite Representative to enable this setting.

• Avature must configure the User Roles to be mapped to BrassRing User Types.

Process

1. Avature must provide the client’s [shortname] (account name) and the [Web Service info] (Username, Password, and Web Service URL) for both Staging and Production.

2. Create a manifest for the Avature Candidate Import. Select Tools → Integrations → Administration

3. If there is no Integration Type of [Candidate import], then select  Add Integration type, select  Candidate import, and select  Save.

4. After the [Candidate import integration type] is available, select  Subscription Admin icon.

5. Select  Add subscription.

6. Complete the [Subscription] and [Subscriber] tabs.

   1. The Subscription name and Manifest name must match. Up to two underscores are allowed, for example: AVATURE_CANDIDATE_UPLOAD

   2. Select the Stacking Logic. It is recommended to select the same stacking logic as the external Talent Gateway.

   3. An Attachment category can be selected, but it is not required.

      

   4. Select  CRM import

   5. On the [Subscriber] tab, select  DefaultVendor.

      

7. Ensure that the manifest name is provided to Avature.

8. Create a Source Code to be used for leads sent from Avature into BrassRing. All source codes that are sent from Avature are prepended with this Source Code. Select Tools → Settings → Code Types.

   1. Select the  Administer code list icon for the Source Code table.

   2. Select  Add new code.

   3. Insert the Code details as needed and select  Save.

      

9. Create an Import Code. This code is attached to the candidate when they are sent from Avature into BrassRing. This code can be similar to the Source code, but cannot be the exact same. Select Tools → Settings → Code Types.

   1. If there is no Import Code Type, select  Add new code type.

   2. Name the Code type and Description [Import] and select  Save.

      

   3. After the Import Code type is available, select the  Administer code list icon.

   4. Select  Add new code.

   5. Create the Import Code type, for example: [AVATURE_IMPORT], and select  Save.

      

10. Open a support ticket with the following details:

    [Please configure the Avature integration for the [Client Name] Staging environment. These are the details.]

    • [Client Short Name: [provided by Avature]]

    • [User Name: [provided by Avature]]

    • [Password: [provided by Avature]o Web Service URL: [provided by Avature]]

    • [Import Code: [the code created in step 9]]

    • [Source Code: [the code created in step 8]]

    • [Manifest Name: [the manifest name from the integration created in step 6a]]

    • [User Type Mapping: [Provide BrassRing User Type Name > Avature Role Name > Avature Role ID.]]

11. After the Infinite Engineering steps are completed, Infinite responds with the Integration User Employee ID Code, Credential (Client ID), manifest name, source code, and import code. These details must be provided to Avature.

12. Enable the User Type settings for the user types that need to access or work in Avature. The [Unlink Candidate] feature is not available for Avature.

    1. Select Tools → Users → User Types.

    2. Select the  Edit type permission pencil icon for the user type.

    3. Select the Integration 2  Set privileges pencil icon.

    4. Enable the CRM privileges and select  Done.

       

    5. Select  Save.

13. Update the Talent Record ribbon configuration by selecting Tools → Users → User Types.

    1. Select the user type and select  Screen display defaults

    2. In the pane to add the link to, select  Select field and select  2xB CRM Record.

       

    3. Select  Save.

14. Enable the [Talent Gateway] setting to allow the Apply URL to be created in the campaigns by selecting Tools → Talent Gateways.

    1. Edit the Talent Gateway to be able to pull the Apply URL for.

15. Enable the setting  Add as job apply URL option to Posting Partners. This box might already be checked if the client is integrated with one of the posting partner vendors.

16. Select  Save.

INTEGRATIONS - AVNET

Abstract

Product:  Workbench

Avnet Integration

This page describes the process for configuring an Avnet integration for BrassRing on Cloud.

Process

Add A Project

1. Initially a New Project has to be created for your organization. Select Tools → Integrations → Mapping Tool.

2. Select Add project.

   

3. Enter the  Integration Project Name.

4. Select  Candidate Import for the  Integration Type.

5. CSC Name and  Integration Consultant are optional. If no integration consultant is selected, after making a version of the draft, then the version is approved.

6. Select  Add.

   

7. Enter the integration instance  Name,  ClientSystem,  ClientSytemVersion, select the  Stacking Logic, and select  Save.

   

8. Select  Project Name in the  Project Name section.

   

9. Select the  Project name in the  Mapping Draft Details section and select  Map Draft.

   

10. Select  Candidate Import for the  Integration Type.

11. Select the  Integration Instance for the selected Integration Type. This is the instance name defined in step 7.

12. By default the Mapped Fields section contain the various Candidate Import fields. Select  Save.

    

13. Select  Approval.

14. In the  Project Approvals page select  the Draft project and select  Make Version. The new version is then created.

    

Project Configuration

A project is ready for configuration when it has been both approved. On the Project Details page, the Approval and Sign-Off columns are both set to Yes for the project. You must configure a project for Staging before it can be published to Production.

1. To configure a project, select Tools → Integrations → Mapping Tool.

2. Select the  Project Name in the  project section, then select the  Product version in the  Version History section.

3. Select the  Configuration tab. The  Configuration page displays. The first time you configure a staging project, the  Configured and  Published columns are set to  No for each integration type or integration instance contained in the signed-off project.

   

4. Select the  Instance Name in the  Staging section and select the  Configure Instance icon.

   

5. The Candidate Import integration is now available for testing within the Staging environment.

6. After the testing has been completed, in the Configuration page, select the  Instance Name in the  Staging Section and select  Publish to Production.

7. Select the  Instance Name in the  Production section and select the  Configure Instance icon.

TROUBLESHOOTING INTEGRATIONS AND REVIEWING THE INTEGRATIONS DASHBOARD

Abstract

Troubleshooting Integrations and Reviewing the Integrations Dashboard

Troubleshooting Integrations and Reviewing the Integrations Dashboard

XML Integrations – Integration Tools

For XML Integrations, select Tools → Integrations → Integration Tools. Select  Retrieve client posts to search XML logs for past transactions.

To access the integrations dashboard select Tools → Integrations → Integrations Dashboard. The Dashboard provides a comprehensive view of the integrations and transaction logs, including your Onboard integrations,

Premium XML Integrations

Premium XML Integrations are those where input data is provided over FTP in XML or Flat File format. Then, the data is transformed into XML and processed.

Custom Integrations

The Integrations Dashboard can be used to access specific Custom Trigger integrations and see individual transaction datetime, status, among other details.

SSO Integrations

The SSO Dashboard lists the client’s current certificates and their expiration dates. You can check if the expiration date is coming up. PSE requires 30 days heads up to staff a certificate change request.

Candidate Export Integrations

The settings for candidate export integrations are viewable in the integrations dashboard.

Infinite Required Log Review

The following integration components require Infinite involvement as their logs are restricted to specialized tools.

• Layer 7 (2-way SSL Certificate, TLS, XML Transformation).

• Message Level Encryption (RSA, AES).

• Talent Gateway profile Import.