thankQ Help

UI Actions are any actions taken by a user. These include, beginning the next step in the workflow, altering data, de-duping suspect contacts and selecting the Re-Validate option.

External Process are actions performed outside of thankQ, by other companies.

Import Status, represents a change in the status of the Import record.

Record Status represents a change in the status of the data records following the completion of a particular step.

Process Steps are actions performed during the import process. Typically these will be stored procedures.

System Steps are actions performed by the thankQ client, or thankQ Service.

Diagram Legend

Whenever an import is set to Cleansing, any record with the status Updated by User is reset so that is goes through the process again.

Clean Data is responsible for cleansing the data and ensuring it is accurate. Spaces are trimmed from the field and blank strings are set to NULL.

If the Operational Country is Australian, and the Country field in Contact or Contact Address is Australia or NULL, then the phone numbers are formatted in the thankQ standard and validated to ensure they are valid phone numbers. Any records with invalid phone numbers are set to Validation Failed.

If the customer has a Batch PAF product setup in thankQ, the addresses are cleansed with the 3rd party tool. Any invalid addresses are set to Validation Failed.

Validating confirms all data meets thankQ requirements.

It validates the data types that against what is in the thankQ tables, to ensure all numbers, dates, booleans, and strings will be of the correct type and length. It will then perform updates for boolean fields to ensure they have a value that can be placed into thankQ (i.e. 1 or -1). Dates are also updates to be in a standard format (yyyy-mm-dd hh:mm:ss), previously they are tested based on the format defined in the configuration (i.e. dmy or ymd, etc).

Contact records are deduped against thankQ records, and can be de-duped automatically, assigned as new automatically, or assigned as Suspect and requiring a thankQ user to choose.

Other records are either de-duped or identified as new.

The records will get a De-duping status during this process when it needs to update related records in the import with the new ID.

Records are then checked for duplication (not to be confused with de-duping, 2 different processes). This check is to prevent records in the import from updating the same record in thankQ at the same time. If automatic re-processing of duplicates isn’t turned on, the duplicates will be set to Validation Failed, however if it is turned on it will mark them as a duplicate. Either way, the next time the import is re-validated, if the first record has been posted to live, then the next duplicate will proceed through the import.

The records are then validated against thankQ requirements. These requirements may be mandatory fields if the record is new to thankQ, or fields required for business logic in thankQ. The configurable validation options in thankQ are also applied at this point. Any validated error will cause the record to be in Validation Failed status.

The foreign keys within the import tables are also validated to ensure all foreign keys actually link to another record.

The final step in the validation is to check the records in the import that the foreign keys link to. If these records have failed validation, then the linked records will be set to Waiting to Update, and it won’t proceed until the linked record can proceed.

If the record has passed all the validation, the next step is update. There may be an intermediary step if pledges are being imported that require tokenisation, in which case that step will be Requires Tokenisation.

Tokenisation is a process run from the client or thankQ service. It will tokenise the credit cards, and any that fail the process will be set to Validation Failed.

Update is where any business logic required on the import records (prior to importing into thankQ) is applied. This logic will typically focus on the record being updated, but where required will create additional records within the import to facilitate updating of other tables (i.e. importing a pledge record may require creating pledge instalments records as well).

The Re-Sequence step involves assigning a thankQ sequence number to any record that was not de-duped. During this process, records will be set to Re-Sequencing when they have to update linked records.

At the end of this step, the same foreign key checks described in the Validation process are performed to ensure all linked records are still OK.

At this point, Importing is a straight forward process. For each record, if it does not exist, the required fields (plus any fields not to be updated) are inserted into thankQ. Then an update is performed on all thankQ records linked to the import records.

Once the import is in the Records Imported stage, all data available for posting into thankQ has been done. If there are no more remaining records to be imported, then the import is set to the stage Import Complete. However if there are records set to the Duplicate status, and there are no Validation Errors and no Suspect Contacts, then the Import is set to Records Imported in order to process the duplicate records. If there are Validation Errors or Suspect Contacts, then it will stay in the Records Imported stage until a thankQ user updates the records and re-validates the import.