Tips for working with data fields

Working with data fields, data tables, and data templates is far more than just entering content into programmed forms, cells, and slots. There are multiple factors to consider so that the data reflects both accurate content as well as accurate format. Data is read by humans but processed by software which can make the format of the data entry just as important as the content itself. The following list highlights several of the factors Beeline Enterprise users should be mindful of when working with system data.

• REQUIRED FIELDS: When you open the downloaded template file, hover over each column header field to view instructions on how to enter data into the template.

• CLIENT REQUIRED FIELDS: As noted, required fields are identified by an asterisk or in the Comment tags but your program may have additional fields that are “required” for your specific program but are not designated as such on the templates. For example, the Cost Center Owner is not a required field but for some clients the Cost Center Owner is the Timesheet Approver, which makes this field “required” for that program’s purposes. Be aware of any instances where your program might have un-designated “required” fields and make sure you enter template data accordingly.
• STORED TEMPLATES:Templates are subject to change without notice so ALWAYS download a new template file for each import process to make sure you are using the most current version!
  As a “best practice”, however, you should download and store copies of all import files in a location that is accessible to all Program Office staff who have Web import Tool access rights. These files can be used to track your system updates and as a sample file to create new import files in the future—take care to use a new download of the template and not just a copy/paste of this previous file to ensure that the new file reflects CURRENT data settings. Do not rely on the imported files stored within Beeline Enterprise because they are purged on a regular basis.
• “CREATOR” vs. “IMPORTER”: If the person who creates/validates the import file does not have import rights, then the Program Office manager with visibility to all import files (Admin – Import View All) needs to facilitate access to the validated file so that the designated Importer can access the file from the Import List screen and complete the import process.
• COMMENT TAGS: Follow the instructions in the Comment tags attached to the Header fields as to data entry requirements. Failure to do so will cause your import file validation to fail. Remember—you are responsible for ALL data you import into ANY client production site. This means that YOU will be responsible for correcting any issues resulting from, or caused by, “bad data” you import into a Beeline Enterprise production site. Take the time to ensure that the data you populate into an import template is the CORRECT data. The time and effort it takes to “correct” data after it is imported is never time well-spent and should any of this data get associated to a finance-related record, it can never be deleted since all finance-related records are retained in the financial datawarehouse for audit purposes.
• WHICH IMPORT PRECEEDS ANOTHER: Be aware that some templates are more complex than others and some templates need to be imported in a specific order. There are too many details to list them all here. Check the Data Imports: How to Guide section in the Appendix for guidance.
• ADJUSTMENTS TO THE TEMPLATE LAYOUT: NEVER change the arrangement of the columns, add or delete columns, or hide columns in a template. If it is not designated as a required field and it is not a field that is relevant to your program, then leave it blank. The validation tool requires that ALL template fields are included on every import file and that the fields are arranged in the same order as the default template.
• RATE CARD IMPORTS: All Rate Card imports must include a default rate card and the line items for the default rate card must be listed BEFORE supplier-specific rate cards. The only exception is when ALL requisitions will be released to the SAME supplier, which is a rare event. The default rate card is assigned to the initial request; the supplier-specific rate cards are assigned to the respective candidate submit.
• DATA FIELDS WITH “NAMES”: The importance of consistent data entry when populating “Name” fields cannot be overstated. Examples include First Name, Last Name, or Middle Name, but it could apply to any data field used as a “name” label. Develop standard protocols and enforce them! Avoid duplicate entries since they can negatively impact downstream system functionality such as Resource Matching, Tenure Tracking, Candidate History, budget-related reporting, report results in general, and Beeline Analytics reports. Remember, the Import Tool is a processor that validates data based on format and Beeline requirements. This data populates throughout Beeline Enterprise including dashboards, <search> results lists, system reports, and Beeline Analytics so the importance of proper data entry cannot be overstated!
  For example: JOSE VALDEZ, Jose Valdez, jose valdez, and José Valdez could be the very same person, but the system processes these names based on format and therefore would create a separate record for each format (e.g., ALL CAPS, Mixed Case, lowercase, names with diacritic letters). If you copy/paste name entries from a third-party source, take care that the original does not include letters with diacritics or characters that are not standard to an English language keyboard. In the digital world, every letter has a unique code, and EVERY variation of that letter has a unique code as well. Therefore, E, e, é represent three different unique codes. The system accepts the text as entered and although the subsequent record can be selected/submitted, any <search> will never generate a “match” since a standard English keyboard does not include diacritic letters or non-standard special characters. Search results will be an EXACT match to your typed entry.
• HYPHENS AND DASHES: A variation on the avoidance of diacritics described above, is the careful use of hyphens to separate words. Use a single hyphen and ONLY a single hyphen, never two adjacent hyphens. Why? Because Word® and Excel® frequently convert hyphens used as spacers to either an “en” dash or an “em” dash and the validation process typically accepts one format but not the other. A hyphen is the width of a single space, an “en” dash is a space and a half, while an “em” dash is two spaces in width. Stick with a single hyphen and your entries should not end up in the Error List.

• COMMAS WITHIN A DATA FIELD: Traditionally, the most common format for a data export file was .csv (comma separated value) since it was the standard export format for Excel. The format has changed to xlsx, but care still needs to be taken with how you use a Beeline export file as an import into a third-party system. If the third-party system is based on .csv functionality, the import will <break> at every comma by shifting to the next column. If you include a comma WITHIN a data field, the column alignment in your third-party file will be out of alignment because the import process will <break> at the comma entered, rather than the end of the data field. This is frequently encountered with Last Name data fields. John Smith, Jr. should have a Last Name data entry of Smith Jr., not Smith, Jr in order to avoid the potential for this error. In general, it is best to avoid using any punctuation internally in any data field that could be used as a delimiter in an extract/import process to ensure the transfer of data runs as smoothly as possible.
• SORT ORDERS: The visible display for any <search> results list is alphabetical for text and descending numeric for numbers. Depending on several factors (program language, code, server settings) an alphabetical list could be separated into sections based on the format used for the letters. In a strict ASCII (American Standard Code for Information Interchange) sort (i.e., ACSIIbetical), all UPPERCASE letters precede all lowercase letters precede all Mixed Case letters—and numbers precede all letters. If you consider the case of Jose Valdez (See: DATA FIELDS WITH “NAMES” entry above.), this could result in three separate sections in a single alphabetical list—all caps items would sort first, followed by all lower-case items, and the mixed case items at the end. Just be mindful when working with data from other systems that the data you import into Beeline Enterprise should generate a SINGLE sort in the results list.
• LEADING INDICATORS: Supplier company names that begin with “A”, “An”, or “The” can be problematic in alphabetical lists. A, An, and The are known as leading indicators. Since digital processing has no comprehension of the meaning of words, it treats these letters like any other, even though to the human reader, their usage in this instance is strictly grammatical. A and An are the least problematic since they alpha sort near the top of your Supplier list—“The” is the problem of the trio. The Eastridge Group is the legal name of a staffing agency. The template instructs you to enter the Supplier’s legal name. If your Supplier list requires significant scrolling, how many of your users are going to scroll down to the “T” section when looking for this Supplier—especially when they scrolled through the “E” section first and saw no entry for “Eastridge”? And how long before someone creates a separate Supplier profile for “Eastridge Group”—which risks negatively impacting system report results, not to mention budget and invoice tracking since you now have TWO profiles for the same Supplier. Spare yourselves the misery! Develop a Program Office policy for leading indicators and broadcast it to all users so they know where in a list to look for these “exceptions”.
• FEED / INTEGRATION FILES: Does your program use feeds or integration files to update your client data? If so, factor that into your manual import process. Client Users, OUs, and Cost Centers are the most common feed files, however there can be a variety of others. Depending on the settings/actions assigned to the integration process, the data you processed in an import file could easily be changed by a subsequent scheduled feed or integration. Check with your Program Office as to scheduled feeds or integrations to avoid overlays.

More insights on working with system data are available in our Web Import Tool Guide article, located here.