Document toolboxDocument toolbox

Contacts Imports

Owned by Brian Dixon
Last updated: Mar 05, 2024
7 min read

Capability

The Contact Import allows Users to Import records into the Workers / Contacts Grid. When an existing Contact record is included in the Import File, and no changes are present, that line of the file will be skipped.

Matches On

The Contact first attempts to match the Customer Number then the Email Address. If there is no match, the record from the Import will INSERT. If there is a match, the remaining fields can UPDATE.

The Import process can be optionally set with Conditional Logic to match on the First Name and Last Name fields with the flag CONTACTS_CHECK_NAMES. See the Conditional Logic section for more information. First Name and Last Names, ONLY IF FLAGS.CONTACTS_CHECK_NAMES is True. If a match is found, that Contact can UPDATE.

For most Import types, the Import Process cannot update the field(s) used to look up the record being updated, because the Import can't provide the lookup value and the new value in one field. But because the Contact import has three different fields it can use for lookups, it works a little differently.

If a match is found, it is possible to update the fields that were not used for the match. For example, if the Contact record was found using the Customer Number, then a new Email Address will be appended, and First and Last Names can be updated. If the Email Address was used for the match, then the Customer Number and Names can be updated.

Fields

First Name

Required

Datatype is String.

Last Name

Required

Datatype is String.

Directory

Datatype is Boolean.

Defaults to False [0].

Contact Type

Datatype is String.

Defaults to Customer.

Permitted values are from the CUSTOMER_TYPE List Values: Customer, User, Coordinator, Guest, Service Rep, Vendor, VIP, and Worker.

Any values added by a User to the CUSTOMER_TYPE list can also be used.

The Contact Type can be provided as an array in the Conditional Logic to allow assigning multiple values.

These values can be hardcoded into the Conditional Logic, or they can come from multiple fields in the input file.

See the Contact Type Notes section below for some examples.

If any Contact Type value is provided, it always replaces any existing value.

If the Contact Type is Coordinator, the following fields are available:

Allow Coordinator Bill Email

Datatype is Boolean.

Default value is False.

If the Contact Type is Customer, the following fields are available.

Customer Number

Conditionally Required

Datatype is String.

Billing Group

Conditionally Required, when Customer Contact Type and it is a New Contact Add

Datatype is String.

Title

Datatype is String.

Permitted values are Staff, Faculty, Director, Secretary, and any other value from the Title List Values.

Dept. Hierarchy

Datatype is Hierarchical String or String.

This Import expects the Department Hierarchy code, not the Name.

The value for this field can be the full Hierarachial Path, or it can be just the last part of the Path. If you provide only the last part, then there is a chance that there could be duplicate values in the database. If duplicate values are found, then you will get an error.

Default GLA

Datatype is Hierarchical String.

Default SLA

Datatype is Hierarchical String.

Default Incident SLA

Datatype is Hierarchical String.

Minimum Amount

Datatype is String.

Maximum Amount

Datatype is String.

Street Address

Datatype is String.

If any Address field holds a value, all except for the Address2 field becomes Required.

Address2

Datatype is String.

Country

Default value: "United States"

Datatype is String.

City

Datatype is String.

State

Datatype is String.

States/Provinces use standard 2 Letter Abbreviations for US/Canada and 3 Letter Abbreviations for Mexico.

Zip Code

Datatype is String.

Address Type

Datatype is String.

Blank values are NOT allowed.

Permitted values are from the ADDRESS_TYPE List Values: Billing, Warehouse, or Office.

Any values added by a User to the ADDRESS_TYPE list can also be used.

Values not in the List are not added.

Email

Datatype is String.

Email Addresses never get updated or removed. If a new Email Address is provided for an existing Contact, it will get appended to the list of Email Addresses, and the new value will be marked as 'Primary'.

Permitted GLA

Datatype is String.

Permitted Values are NONE, ALL, or any valid GLA. NONE removes all entries in the list and add the Permit None record.

ALL removes all entries in the list and allow any GLA to be used.

For the first occurrence of a Contact in the import file, if a GLA Permission value is provided, this will replace the entire list of existing GLA Permissions for this Contact. Successive lines in the import file will append GLA Permissions. There is no way to just append individual values. The entire list will get replaced by the import.

Adding any valid GLA to the list removes the Permit None record.

To add multiple Permitted GLAs, each must be on a separate line of the Import File.

Phone

Datatype is String.

By default, this option allows numbers in these formats: "(123) 456-7890" or "456-7890" or "4567890".

Multiple Primary Phone Numbers cause an error.

The format of the Phone field is validated against the formatting.filters.phone.match configuration option. If the value does not match one of the default formats, it will cause a warning and the phone number will not be added.

Status

Datatype is String.

Default value is Active unless the CONTACTS_INSERT_INACTIVE flag is set to True.

Permitted values are Active and Inactive.

Flags / Conditional Logic

PERMITTED_GLA_APPEND:

Datatype is String.
Allowed Values are "APPEND" and "CLEAR".

This flag controls how GLAs are added to the GLA Permissions tab.

  • If you set APPEND, the import will append values.

  • If you set CLEAR, the import will clear all existing values before adding any. You can send the CLEAR value to just clear the list without providing a new value.

  • If you don't provide this flag, then the default behavior is to clear the list before adding the first value in the input file, then append any additional values that are in the same input file.

UPDATE_CONTACT_EMAIL:

Default Value is True.

  • True: If True and the provided email address is not associated with the Contact, the Import adds the provided Email Address to the Contact and makes it the Primary Email Address. Any previous Email Address values are left in the list. This Import never updates or removes existing Email Addresses.

  • False: If this flag is False, the email field is not saved.

UPDATE_CONTACT_PHONE:

Default Value is True.

  • True: If the provided phone is not in the Contact, the Import appends the provided Phone to the Contact and makes it the Primary Phone. If the Phone Number is already on the Contact, the Primary flag does not change. Any previous Phone values are left on the list. This Import never updates or removes existing phone numbers.

  • False: The Phone field is not saved.

UPDATE_CONTACT_ADDRESS:

Default Value is True.

  • True: The Import will UPDATE the existing Contact Address.

  • False: The Import does not save the Contact Address.

CONTACTS_CHECK_NAMES:

Default Value is False.

  • True: The First Name and Last Name are used to see if the Contact already exists. If BOTH First Name and Last Name match, the Contact is considered matched, and the Import attempts to UPDATE the existing record with the data from the Import File. Otherwise, the Import attempts to INSERT the Import Record.

  • False: This check is not performed.

NEW_CONTACT_DEFAULT_BILLING_GROUP:

Default Value is Blank.

  • This sets the Billing Group value for new Customer Contacts.

NEW_CONTACT_DEFAULT_CONTACT_TYPE:

Default Value is Blank.

  • This sets the Contact Type value for new Customer Contacts.

CONTACTS_INSERT_INACTIVE:

Default Value = False

  • True: If set to True, new Contacts attempts to INSERT with an Inactive Status.

  • False: If set to False, the new Contact attempts to INSERT with an Active Status.

Errors

When an Import Line fails, it is usually because the Line falls into one of the following categories:

  1. The value provided from another table was not found within the Database





  2. The value provided from another table has multiple possible values





  3. A blank value was provided, for a field with a required value





  4. The value provided is not acceptable for the record type being created





  5. The System was unable to save the record





Contact Type Notes

Often you will need to specify multiple values for the Contact Type. Sometimes it is required. For example, in order for a Contact to be a Coordinator, it must also be a Customer.

To specify multiple Contact Types, you must use Conditional Logic to set the Contact Type to an array of values.

Example 1: You can hard code multiple values. These will apply to every Contact in the input file.

[CONTACTS_TYPES.CONTACT_TYPE] = array('Customer', 'Coordinator');

Example 2: Contact type(s) are in columns 5, 6, 7, and 8 of the input file, one value per column. This method limits the number of Contact Types per Contact by the number of columns you want to use in the file layout. The import will ignore any blank values that get put into the array.

[CONTACTS_TYPES.CONTACT_TYPE] = array([5], [6], [7], [8]);

Example 3: Contact type(s) are all in column 5, with commas separating the values. We can use the PHP explode function to convert the comma-separated list into an array. The function will also work correctly if only one value is specified. If the separator is something else, just change it in the first argument of the explode function.

[CONTACTS_TYPES.CONTACT_TYPE] = explode(",", [5]);

UDF Associations

User Defined Fields on any given Import are all handled the same way with Conditional Logic. For more information about adding a UDF to the Import, see the User Defined Fields section of the Imports main page.