Release Notes - February 27, 2017

Print Friendly and PDF Follow


Product Functionality

Event Audit/Transactional Report

A completely revamped new audit detail export of all the registrant activity that displays edits, adjustments, and additions behind each primary and guest registration will be available February 27, 2017. 

Where can I access the Audit/Transactional Export? 

From Events --> Reports you can access the 'Create New Export' button under the Optimized Report heading. From the new window you can select an additional Custom Event Data Export type called Audit/Transactional Export once the flag[EnableAuditEventExport] has been enabled.

Will I be able to Configure Data by defining an Export Type (i.e. Specific Activities, Main Event, Event data with all related activities...)

This export type by design will pull all event data with all related activities (if applicable) and categories. Report will also be supplied with canned fields at the beginning of file:  Const ID, Member ID, First Name, Last Name, Action Date, Registration Count, Registered By, Order Total, Email Address.

What is the Action Date column and what does it track?

Action Date will date stamp when the action for that row occurred. If a constituent registers on 1/3/16 and later changes their registration on 1/4/16, each row will give you the details that occurred on those respective dates. This feature is great for admins who want to track when an influx of registrations came in or if multiple people canceled on a certain date - admins can tie it back to what may have triggered the action. 

Will this report show the user/admin who adjusted/submitted a registration?

This report is designed to show you any user (constituent, admin) who submitted or changed an existing registration; however, this feature is only meant to track things moving forward from when the flag is enabled. Pulling a report today will not have data populated in the new "Updated By" column.  

What column can I use to group submissions together?

If an admin adjusts a record, the 'registered by' column will be blank for that row as it does not apply in that scenario. For grouping purposes, admins can use the 'Submission ID' column for a unique ID that groups all registrations/edits that were done for that party.

What is the purpose of the Submission History ID?

The 'Submission History ID' column's intended purpose is to provide the same ID for records submitted together while registering. This can allow for easy grouping as well as provide great metrics on when people may have registered for certain things since date stamps are provided for each action. Each new submission will have contain a shared ID value for that party.

What is the purpose of the Adjustment ID?

Adjustment ID column will display a unique ID for each adjustment for admins who want to mark off line by line, or is a great way to report progress that they have processed adjustment ID 1614-1700, for example.

What happens to the export output when I merge a guest/non-member record with their constituent record?

This row will now contain a value for Constituent ID (Client's Primary Key) and member ID will change but their registration details will remain the same.

Can I add additional member fields or change the sort order of them in my export?

If you would like the field to be available on your export, you will need to add those respective fields to the event form. Once added (in Admin or Constituent facing categories) it will then be available in your export.  Field order is determined and follows the order in which they display on your form... from start to finish.

When applying a date filter on when users submitted the form, which rows should I expect to see?

The export will provide any rows with the action date that met your date range criteria regardless if the row is a registration, adjustment, etc.  If the row reported has an associated (debit or credit), it will pull in that row in this file in order to properly reconcile despite being out of the date range you indicated.  Below we applied a date range of 11/16 through 11/18:


(Even though Omar registered on 11/17 and canceled on 2/8, both transactions will display for Audit purposes so you never have to chase down when associated rows may have occurred.)