Skip to main content

Employee Assignment Flexible Header Import - Header Row Details

The first non-blank row in the import file shall be interpreted as the header row.  The header row shall be used to define which fields will be imported (as such, they are referred to as field-definit

Updated over 2 weeks ago

The first non-blank row in the import file shall be interpreted as the header row. The header row shall be used to define which fields will be imported (as such, they are referred to as field-definition columns). The first five columns of the header row should contain these captions (in order): Employee Command, Assignment Command, Employee Number, Assignment Number, and Assignment Identifier.

The sixth column of the header row is the first “field-definition” column. Each field to be imported shall occupy one column. There should be at least one such column, and there is no upper limit to the number of columns. Every such column should be unique within the header row (no duplicate columns).

The format for each field-definition column is <table name>!<field name>. For example, in order to update the LAST_NAME field of an EMPLOYEE record, the field-definition column should be EMPLOYEE!LAST_NAME.

If data is being updated in Multi-Record User tables, the header row must also indicate which fields are key fields. Key fields are indicated by appending |recordIdentifier=true to the end of the field definition column. The key field(s) tells the system which record to update. For example, if a column is named “UT_CUSTOM_TABLE!CUSTOM_NAME|recordIdentifier=true” and the value in that column of the import is “John Smith”, the system will find a record in the CUSTOM_TABLE table that has “John Smith” in the CUSTOM_NAME field and update that record. Note that if multiple fields are key fields, a record must match on all of those fields in order to be updated. If a column is set as a key field and no match can be found, then the record in the import file will be inserted.

If data is being updated in Single-Record User tables, identifying key fields is not allowed, since Assignment Number is always the key field for an assignment. The presence of |recordIdentifier=true in any field definition column will therefore cause an error. If the system finds the Assignment Number in a record in the CUSTOM_TABLE, the import will update that record. Otherwise, it will insert the record.

If you want to link an assignment to another in Dual Career Move, you must include both

ASSIGNMENT!DUAL_CAREER_TYPE (which takes values of either ‘leading’ or ‘trailing’) and ASSIGNMENT!LINKED_ASSIGNMENT_ID (which takes the Assignment ID, not Assignment Number). If an invalid value is given for either of those columns, the current import row will be skipped and you will get an error message. Note that ASSIGNMENT!IS_DUAL_CAREER_MOVE is a calculated column and is not allowed to be imported to. Just like when linking Assignments on the Assignment Details screen, if you want to link Assignments, your assignment must be an International Relocation and the Assignment you want to link to must be an International Relocation and cannot already be linked to any other Assignment. You are allowed to include Dual Career Move data during an Assignment INSERT, but the assignment specified in the LINKED_ASSIGNMENT_ID field must already exist in the system before the import is run. If you want to unlink an Assignment during an UPDATE, use the value of ‘<blank>’ for either or both columns and the import will remove the link.

Did this answer your question?