There are many types of logs in Digital-Clay that help locate an issue, configuration problem or bug:

• Every data form has a History button for keeping track of who changed what and when. This includes field changes, record merges, attachment changes, and record add dates (which may not always be the same as the record created date when synchronizing or importing data).

• Histories can also optionally display the actual values set per field by using the “Save Value History” feature in the Field Properties. Note that the value stored is always the new value. If the property was set to save values before the item was added, the original value is saved in the history as soon as the item is added (e.g. if Customer:Name is set to store values, when the Customer “Microsoft” is added, a history entry is saved that shows “Name: Microsoft”. When the customer is changed to “MS”, a new history entry is saved on that date that says “Name: MS”.)

• Deletions: The one exception to auditing is when records are deleted (not merged): If the record is deleted from inside Clay, you can try searching for it in the Deletions table in the database. This isn't very useful however unless you know the item ID or are looking for a number of deletions in a specific date. Deletions are permanent and brutal which is why items should normally be inactivated or merged, not deleted, and regular users should never have permissions to do so.

Sample Uses:

• When data inexplicably changes, this is useful for tracking down who changed it and when.
• Auditing
• Backups may be restored based on history dates

• If the Automation action was successful and it involved changing a field value, you can check for it in the item History. Automation changes are always stored under the user 'System'.

• If the Automation experienced an error, it will add an entry to the Automation Log. Typical errors that may occur are “Insufficient permissions”, validation errors, various send-mail errors, or when a field/link no longer exists.

• If the Automation filters/requirements didn't pass, no log entry is stored.

Sample Uses:

• Since Automation runs in the background, the histories and automation logs are the only way to debug problems or verify that actions were run.

• Note that when there are conflicting or multiple automation actions, the use of histories is invaluable in determining which action ran first or last. This is also useful for tuning automation priorities.

• Automated e-mail sending: All errors to do with SMTP servers or specific bad e-mail addresses are logged in the automation log.

• Importing Data: Unless an error occured, you can track exactly what was imported, skipped or merged on a record level by clicking on “Create log file” in the Integrator.

• This setting is saved in the session file and therefore works also during automated/command line imports.

• The log file is stored under \DigitalClay\ClayIntegrator in .csv format with one source record per row with a column that states what was done for that row. For example, if a record was skipped due to there being a duplicate in the source, it will say “Skip duplicate in source”. If the record was updated instead of added, the log will indicate this as well.

Sample Uses: When the final number of imports and updates don't match expectations, this is one method for analyzing the discrepancy by finding missing records and reading why they were skipped or whether they were updated.

• Both successful and failed injections are stored by default under \DigitalClay\DataInjection.

• The complete injection data is stored in a txt file. This is useful for checking whether the data was received fully and in the proper format.

• Failed injections are stored along with a descriptive error message.

If there was an error or problem with the update, or if you need to check when the last update ran and what it updated exactly, there is a detailed log file under \Windows\System32\WebUpdateSvc4.log

• Central and all Clay clients each have their own log file under \Program Files\Digital-Clay\. Most unexpected errors are saved in these files by default with further technical details that may help R&D in tracking down a bug.

• If the client crashed and exited, that usually means the error was not caught and therefore it will not appear in the log file.

• Note that since ClayStation for Outlook runs as an add-on, the equivalent of a crash for this client is a generic runtime error message box AND the ClayStation add-on being disabled (i.e. the ClayStation buttons no longer work until Outlook is restarted). If Outlook itself crashes and exits, this is most probably an Outlook problem and not due to Digital-Clay.

• It is important to take note of the exact time the problem occured so that it can be compared to the timestamps in the log file.

• For Outlook and e-mail communication issues, more detailed logging can be analyzed by setting LogLevel=4 in the registry under the specific client's (or Central's) registry subkey. This setting should only be set temporarily however.

Sample Uses: When submitting bug reports to R&D, these log files should be checked for relevant errors and if entries exist, the log file should be submitted with the bug report.