Text File Importing for HRIS Integration: Client FAQ Page

Document created by 2739823 Administrator on Feb 16, 2015Last modified by 886514 on Jun 14, 2017
Version 15Show Document
  • View in full screen mode

Why would we want to set up HRIS integration?

The advantages to setting up HRIS integration are extensive and include significant time savings, reducing and/or eliminating data entry, improving the accuracy of learner data, improving reporting data available, and maximizing leaner allotments in the RLMS.

 

What is the cost to set up HRIS integration through text file importing?

Relias Learning does not charge any set-up fees for HRIS integration.  It is a free service to our customers.  Please check with your HRIS vendor for any potential set-up fees the vendor charges for creating a custom text file.  It is common to see a charge anywhere from $0 - $3,000.  However, this fee will produce a strong return on investment and should not deter you from setting up HRIS integration.

 

What fields are required on the text file?

The only required fields are: Entry Type, OrgID, OrgCode, LastName, FirstName, Username, Password, Active, and Restricted.  We highly recommend including hierarchy as a required field.  There are also many other fields we recommend (see below).

 

What additional fields do you recommend?

Relias Learning highly recommends using the following fields: HireDate, Email, JobTitle, Department, Location, HierarchyID, any User Defined fields in use, and EmploymentTypes.  In addition, it is imperative that you include any fields that are currently used, or may be used in the future, for auto-enrollment profiles on your curricula.  We encourage you to use as many fields as possible to enhance your reporting capabilities.

 

How often do you upload text files into the RLMS?

Assuming there is a file sent on the SFTP site, Relias Learning loads files once every day around 4-7 AM EST.

 

How often can we send text files to you?

You can send the files as frequently as daily.  Most often, customers send daily or weekly files.  Relias Learning recommends setting the files to export automatically after all jobs are complete for the day within your HRIS.  The file must be sent by 12 Midnight EST to guarantee that the file is received and processed the following morning. 

 

Do we need to encrypt the files?

No, please do not encrypt the files.  The files are sent to a personalized secure FTP (SFTP) site.

 

If we decide we are interested in setting this up, what is the timeline?

The timeline is dependent on how long it takes your HRIS vendor to produce a test file.  Once the test file is ready, Relias Learning will QA the file within 2 business days and provide any needed feedback on changes.  Once the file is ready to go live, Relias Learning will create the SFTP credentials and send to customer within 2 business days.  As soon as the file is transmitted to the SFTP site, it will be processed as part of the daily run.

 

If we are not using a field, how do we send it on the text file?

Assuming the field is not required, you can leave any fields you are not using blank.  Please note that there are a few fields that if left blank, they will remove existing information from the learner profile (see next question).  Even if left blank, every field must start and end with a pipe character.  Here is an example where the 8th field (GUID) is being left blank.  USER|101|AA1|Doe|John|JDoe|Password||088482|

 

If left blank, what fields will remove existing information from the learner profile?

  • Job Title
  • Department
  • Employment Type
  • User Categories
  • User Location

 

The RLMS username and password are not stored in our HRIS.  What do we do?

There are a few options for managing the usernames and passwords.  The preferred option is to change the usernames in the RLMS to something that already exists within the HRIS (e.g., Employee ID #).  Please contact Relias Learning to help with this process, as we can help with the bulk change prior to the text file import.  A second option is to add the existing usernames and passwords to your HRIS, and have this information created (manually or automatically) for new learners in the future.  Finally, you could use a reference table to look up and populate this information.  See questions below for additional information.

 

What do you recommend we use for usernames?

We recommend using something that is unique to an individual, static (i.e., will not ever change), and a field that is stored in your HRIS.  This would include an employee ID number, a badge number, etc.  We do not recommend using first and last names as those can cause duplicates in your site (e.g., two John Smiths) and will also change when a learner has a name change.

 

What happens if we change a username on the text file?  For example, if Jane Smith’s username is jsmith, and we change it to jdavis due to a name change.

Important: avoid changing usernames in the text file transfers.  In the RLMS, the username is a unique field, and if an existing learner has an update to a username submitted on the text file, a new learner with the new username will be created in the RLMS rather than the existing learner updated.  If you require an occasional username update, please update the username in RLMS manually before submitting a text file with the new username.

 

How should we send over learner passwords on the text file?

The existing learner passwords can be found by exporting your learner list.  There are two main options for managing how to send passwords on the text files, and you will want to determine if you want to 1) allow your learners to update their own passwords or 2) maintain a password established by your company and not allow your learners to update their own passwords.  There is a site wide setting within Settings that shows “Allow user import password updates.” This option tells the RLMS whether or not to update learner passwords based on what is contained in the password field on the text file.

site settings.png

  • Option Enabled: If this option is selected, passwords sent over on the text file will update the learner passwords within the RLMS, even if they changed the password from the time the last text file was imported.  Leave this setting turned on if you do not want learners to be able to reset their password.  For example, some of our customers establish learner passwords and do not want these changed (e.g., last 4 digits of SSN).  If the site setting is selected, passwords will remain what is included on the text file.
  • Option Disabled: Leave this option disabled if you want your learners to be able to set and use their own passwords.  You could then send over a generic password (e.g., password) for all existing and new learners.  Existing learners would continue to use their existing password in the RLMS since the text file would not update it to password since you did not select the site setting to allow learner import password updates.  New learners would use the generic password until they logged in and reset it.

 

How should we send over the passwords for new learners?

If you allow learners to set their own passwords, when you send over the learner as a new add, start by sending over a generic password that you use for all new learners (e.g., “password,” “last name + last 4 digits of SSN”).  They can then login and reset the password to one of their choosing.  Alternatively, if you do not allow learners to set their own passwords, continue to assign passwords as you have done in the past and send this information over on the text file.

 

How is a new learner identified?

The username is the identifier that the RLMS uses to recognize a learner.  If a new username appears on the text file and is identified as an Active learner, the RLMS will identify this person as a new learner and create a new account.

 

How do we send over terminated learners?

In order to deactivate a learner in the RLMS, the learner must be sent over on the text file as Inactive.  This is the Active field and a denotation of “0” for Inactive.  Please note that sending a Termination Date alone will not make a learner Inactive in the RLMS, and the termination date, if included, should be accompanied by a 0 for the Active status.  Warning: this rule applies even if you are using the site setting within Settings – Miscellaneous Site Settings to “Inactivate Terminated Users.”  Remember to always send a 0 for Inactive people along with a termination date if desired.

inactive.png

 

Should we send a full file or changes only?

In order to ensure we capture all learners and changes, we prefer to receive a full file with your active learner list, any new hires, and your last 30 days’ worth of terminations.

 

If a learner has a change in a field (e.g., job title), what is the process for submitting the change?  Will sending a new job title create two job titles in the system or will the new one overwrite the old one?

If a learner has a new job title (or department, etc.), all you need to do is send over the new information on the text file.  This new information will override anything existing in the learner profile.

 

Can we send multiple job titles or departments, etc. within a field?  If you can send multiple, how do we separate them?

Yes, you can send over multiple job titles and/or departments as long as they are separated by a semi-colon (;).

 

What fields are reportable?  What fields are non-reportable?

  • Reportable: Hierarchy, Department, Location, Job Titles, Employment Types, User Categories, User Defined Fields (1, 2, 3), Active Status, Hire Date, Gender and Ethnicity on the EEOC Report
  • Non-reportable: Items within User Contact Info (e.g., Address), Organization, Employee ID, Credentials

 

Who creates the SFTP credentials for the customer?

Relias Learning creates the SFTP credentials for each customer using text file importing.

 

What do the following fields mean?

  • Restricted – whether a learner has full access to all of your libraries or if they are a restricted learner and only have access to a sub-section of your libraries.
    • 0 = full user
    • 1 = restricted user
    • You can leave this blank, and it will default to 0
  • Hide from Master – only applicable to Enterprise customers with sub-portals and indicates whether or not to hide the site from the master site.
    • 0 = no
    • 1 = yes
    • You can leave this blank, and it will default to 0
  • Can Elect –whether or not learners can enroll in elective coursework.
    • 0 = no
    • 1 = yes
    • You can leave this blank, and it will default to 1
  • Self-Completion Mode - whether or not learners can self-submit external completed trainings from their My Learning page. This is applicable when the System>Settings feature for "Enable Learner Self Completions" is turned on.
    • 0= Learner does not have the ability to self-submit external completed trainings.
    • 1= Learner has the ability to self-submit external completed trainings with no approval required.
    • 2= Learner has the ability to self-submit external completed trainings for approval by a supervisor.
    • We recommend leaving this field blank as doing so will keep the current settings intact.
  • External Request Mode – whether or not learners can self-submit future external training requests from their My Learning page.  This is applicable when the System>Settings feature for "Future Training Requests" is turned on.
    • 0 = Learner does not have the ability to self-submit future external training requests.
    • 1 = Learner has the ability to self-submit future external trainings with no approval required.
    • 2 = Learner has the ability to self-submit future external training requests for approval by a supervisor to attend the training.
    • 3 = Learner has the ability to self-submit future external training requests for approval by a supervisor to attend the training as well as approval upon completion of the training.
    • We recommend leaving this field blank as doing so will keep the current settings intact.

 

Do most customers send over learner permissions on the text file?  This includes signifying that a learner is a Supervisor, Instructor, Administrator, and/or Skills Checklist Observer or Data Entry.

No, most customers leave these fields blank.  We recommend leaving the permissions blank and managing permissions manually since permission levels above learner rarely change.

 

If we leave the permissions blank (Administrator, Instructor, Supervisor, Skills Checklist Observer or Data Entry), will it remove rights from a learner?

No, if the permission fields are left blank, all existing learners will maintain their current permissions.  All new learners are given the permission of learner regardless of what information is, or is not, included in the permission fields on the text file.  If left blank, additional learner permissions can be added and/or removed manually within the RLMS.  Please note that sending a 0 in this field will remove existing permissions.

 

Is an email address required?

An email address is not required for a learner, but we recommend including an email address so that warning emails are received when courses are coming due or overdue.  We also recommend using email addresses because learners can then lookup a forgotten password.  Email addresses are required for any person that has permissions greater than a learner (e.g., Supervisor, Instructor, Administrator).

 

What happens if we mark someone as an Administrator (or other role that is above a Learner) in the RLMS but do not send an email address on the text file?

An email address is required for all learners with permissions greater than a learner.  If you leave out the email address in the text file, the permissions will remain intact, but the other fields will not update.

 

Where can I find our OrgID and OrgCode?

When logged into your site, click on Settings and this information is found on the left hand side of the page if you scroll down towards the bottom.  OrgID is identified as Customer ID.  OrgCode is identified as Organization Code.

2015-09-25_8-58-57.png

 

Where can I locate the HierarchyID?

When logged into your site, click on Users, Hierarchy, and Export Hierarchy.  This will create an Excel file that contains a list of your Hierarchy IDs.

2015-09-25_9-00-03.png

Will leaving the HierarchyID field blank remove people from their hierarchy?

No, leaving the HierarchyID field will not remove anyone currently assigned to an existing hierarchy.

 

What are the options for managing our hierarchy?  Our hierarchy IDs do not currently exist in our HRIS.

If you plan to update hierarchies in the RLMS through your text file transfer (recommended), you will need to include the hierarchy ID in your text file for each learner.  The preferred method is to simplify and/or modify your hierarchy to match up to existing HRIS fields and create a reference table to pull in the corresponding hierarchy IDs.  A reference table may be able to be used without any modifications to your existing hierarchy depending on the setup in your system.  Another option is to add the hierarchy IDs to your HRIS if a field is available.  Finally, you can continue to manage the hierarchy manually in the RLMS.  New learners will appear as Unassigned within the hierarchy and can be manually assigned to the proper area.

 

If there is an error that prevents a learner record from loading, do we receive any notification or error report?

The technical contact person identified in the site Settings will receive an email notification indicating whether or not the file was successfully processed. Each record included in the file that was processed will have a success or failure message beside them. Please note that success messages will display for all users who have no errors. New users will display "New Record Created" and users moved into an active status from any other status will display "User was Activated".

Contact info.png

 

 

If we decide we are interested in setting this up, what are the next steps?

  1. Identify the fields you want to use
  2. Compare the RLMS fields to the HRIS to:
    • Ensure important fields in RLMS match up to existing data within your HRIS, and if not, update the RLMS to match your HRIS.  For example, make sure job titles, departments, and locations are spelled correctly and not abbreviated. Be especially careful that any fields used for auto-enrollments on curricula are matching.
    • See if the fields exist in the HRIS.  If not, will you add them to the HRIS or use a reference table to get to them?
  3. Decide how to handle managing Hierarchy IDs
  4. Send file layout document along with desired fields to your HRIS vendor for a quote and timeline
  5. HRIS vendor produces test file
  6. Notify Relias Learning that you have a test file ready and submit it to Relias Learning via email. The test file should not be submitted to the SFTP site.
  7. Relias Learning will QA the test file and send the customer any changes needed or approval to go live
    • Common error: if any numeric fields contain leading zeros (e.g., username of 012345), make sure you are sending the leading 0s on your text file and that they are not dropping off during the export
  8. When ready to go live, Relias Learning will create a SFTP site and send you the login credentials
  9. If file is approved, begin to send file daily/weekly to the SFTP site

 

To get back to the Knowledge Base and the master list of topics, please click here: RLMS Knowledge Base

Attachments

    Outcomes