How Contacts Work

Contacts are a record extracted from a document, usually a student. Contacts are created automatically when a process rule on a process step has the correct configuration. A contact is created either when a student’s details are finalised, access to a learning management system is required or the individual’s details need to be updated eg when new information is provided.

Contact details are only created / updated when the Process Rule is executed that has the ‘create contact’ settings specified see the following process rule and notes:
If a Process rule updates the document and there are no ‘Create contact’ settings on the process rule then there is no update of contact information
If a different Contact Type exists on a contact but is matched by the contactId etc then it is added as that new contact type with those details. This is a beta feature, caution.
The Contact matching rules only apply when creating a document for the first time. If a Document is already linked to a Contact then no matching will take place, the Contact which is already linked will be checked and may be updated.
The Process rule needs all fields or no processing will take place, even if the contact is existing.
Updates to contacts are only ever from Document to Contact, ie. a student updating their contact record will not update the registration documents. Documents are a record of a booking at a point in time.

Contacts - How are they used?

Contacts are used to store a contact’s details - usually a student. If the contact form has a password field on it and that field has a valid password the user has access to the student portal and, if the plugins are configured, access to Moodle. When reporting on a student this is where client information is sourced, eg for NAT00080 and NAT00085 files in AVETMISS reporting. Contacts also act as the link between other documents from the same person, based on how the matching of any documents and contacts has been defined.

Contacts and AVETMISS

For Australian RTOs the contact represents the ‘student file’ this is where the information for NAT00080 and NAT00085 comes from. If the Contact form has the field ‘Client Identifier’ on the form with a value in it that is the value that is assumed to be unique and will be used to identify the student in the NAT files, therefor any reference to errors will reference this field value when validating the AVETMISS files. However if the Contact Identifier file does not exist then the ContactId (internal reference number) is used. This is an incremental number unique to each contact.

Keeping Documents and Contacts in sync

Documents could be updated at any time and become out of sync with the Contact, but whether that matters will depend on what you are doing with the Contacts. Typically we expect it to make sense to update at booking and when the course is completed. Beware that too much updating may lead to multiple overwrites - eg two Documents for one Contact, one Document is changed and the Contact updated, then the other one has status updated and the Contact is updated with the old details. Also, Student Portal lets a student update their own Contact; this is better than trying to keep Documents current and maintain sync between Documents and a Contact. Documents are a record of a booking at a point in time.

Scenario one

If you create a contact at booking and then have an attending process step which allows updating of common fields, unless you also add the necessary ‘Create contact’ settings to update the values on the contact the data does not synchronize as per original rule.

Scenario two

You set up a booking process rule and an attending process rule with the same ‘Create contact’ settings, to use the email address as the identifier. If at the attending step the customer changes their email address it does not create a new contact because the link has already been created, the fields are updated as per the configuration on the process rule.

Scenario three

If you want to be sure that details are always up-to-date on the contact form you will need to have ‘Create contact’ settings on all process rules as admin staff could update the document form at any time.

Scenario four

You don’t need to use the student portal nor Moodle, and linking documents is less important so creating a contact at the last step is acceptable. Sample Process Rule configuration for adding or updating a contact record:

Match Contact Using Rule: Use Id to find the contact
Copy to Contact Using Rule: Overwrite existing data where there are differences
Default Contact Id: Use AVETMISS Unique Student Identifier
Default Contact Form: Student
Match Contact Type: Customer
Warning
Now that the USI accepts ‘INTOFF’ and ‘INDIV’ as a value, this means that if you use the USI as the identifier and use either of these (acceptable) values you will end up allocating multiple documents to one contact, resulting in AVETMISS validation errors.

Using contact with the Student Portal and Moodle

The Default Contact Id is the external identifier used by students to access services like the Student Portal and Moodle, the Learning Management System. Creating a Contact will give a student access to these areas if configured to do so.

If any activity changes the Default Contact Id this is also changing the user’s username for online services such as Student Portal & Moodle. The Default Contact Id is setup when the Contact is created, and no automated process updates it (ie no later changes on the Document change the Contact External Id). If it is manually updated the user will need to be informed of their new login details (Student Portal, Moodle).

If the external ID is the email address, changing the email address field is not the same as changing the external id if it is an email address field on the form. So if a student updates their email address their login username does NOT change.

The real link between Documents and Contacts is an internal key, so text changes to Default Contact Ids do not break the link.

Changing / merging multiple documents to one contact

A Document can be linked to a different contact using the Contact autocomplete on the Document. There is currently no way to merge of data between two Contacts, other than manually.

Scenario: Student 1 creates registration Document 1 creates Contact 1, the same student creates registration Document 2 creates Contact 2, via the autocomplete contact field the course administrator updates Document 2 to link to Contact 1. Document 2 is then updated (via attend for example) which updates Contact 1.

Which should you use as the Default Contact Id?

The Default Contact Id is used as the username for the student portal. There is also an internal ContactId that is numerical and assigned automatically. The Default Contact Id is also the student’s username for Moodle when using the authentication plugin. You have a choice when creating contacts. A Default Contact Id is not required. When choosing a Default Contact Id you have a choice of:

Leave Blank

Effectively no ‘external’ Default Contact Id

Use Customer Email

When combining with ‘match contact with rule’ and ‘Use id to find the contact’ it is assumed that the emails are unique.

Note
Using email as a unique identifier to create a contact has its flaws, unless you are sure ONLY the student’s email will be entered into that field and it will be unique for that individual. In the case of AVETMISS if the same email address is used for a number of students, eg a training co-ordinator decides to add a batch of students, and uses his/her email address rather than each student’s email address then all registrations created will be linked to a single contact, namely the last student added by using that email. This will produce INVALID AVETMISS data; only one person will be reported as attending the course multiple times). Using the USI or another unique identifier enables unique identification of the student. Alternatively use a combination of name and email address or some other unique identifier to ensure each individual is correctly accounted for future reporting.

Assign next sequential number

The numbers are incremented automatically, and allocated to the contacts as they arrive. Drawbacks are that the number is tricky to remember by customers, and are therefore unlikely to be reused when making subsequent bookings, so that contacts may be created multiple times for the same customer.

Use AVETMISS Client Id

There is a field ‘AVETMISS 7.0 Client Identifier’ which is used as the reference point for. Drawbacks to this is that it is a manually allocated identifier, prone to human error as it relies on checking and double-checking that numbers have not been used elsewhere

Use AVETMISS Unique Student Identifier (USI)

Uses the USI issued by the Australian government to all Vocational education students as the Default Contact Id. Drawbacks include training organisations who enter the SHORT code while exhempt from collecting the USI, or international students who are allocated INTOFF as a USI, both of these codes can result in one contact being allocated incorrectly to multiple registrations.

Use Document Source Identifier

this is the source of the document such as Moodle Id or another third party where the documents are created. Useful if you want to keep track of the documents via another system, for example this means that when the source updates the document, eg via a completion notification in Moodle, we know what record to update within CourseSales.com. Drawbacks include this id being out of your control, are often long and tricky to remember, similar issues to a sequential number.

Note
When using USI: You should only use the USI as the Default Contact Id to create the contact once it has been verified, using a USI prior to this as an identifier risks matching against a different or invalid USI, the Default Contact Id cannot be updated manually if it is subsequently changed, this means that future registrations, if the USI is not manually updated, will not be associated to the correct contact when combined with ‘match contact with rule’ and ‘Use id to find the contact’.

Contact matching rules for when importing data

Often when importing data from spreadsheet maintained student details, or website databases the information is missing vital information. In particular it may be missing a unique identifier that identifies a customer uniquely. There are often identifiers that match a registration, but not a unique customer or contact. If not correctly identified students multiple contacts could be created for the same student causing issues when reporting AVETMISS or trying to accurately update or identify a customer.

If you find that not all customers have a Unique Student Identifier, other client identifiers are not unique to a specific client, emails are not unique (ie used by more than one person or not used at all) then it is difficult to ensure that contacts can be reliably created/matched for each customer.

Options to deal with data that is piecemeal are:

manually allocate Client Ids or Document Source Ids, and identify unique customers through name, and other identifiers or other databases
take an existing identifier ie Email or Client id and fill in gaps with either generated emails eg client1008@yourdomain.com, or attempt to get the data from the client or from other databases.
accept that duplicates will occur and deal with these as they arrise, use one of the techniques above to ensure that contact are created as necessary.