Backoffice manual

OVERVIEW

• Backoffice timezone is based on browser local timezone.

• Every date-time displayed on Backoffice is converted to local timezone if no specific timezone is mentioned.

The TIXnGO AdminTool is a Management console for every Organizer. It allows them to inject, monitor and edit Tickets, Events, Transactions, Spectators and Custom App Settings. It is accessible at https://console.TIXnGO.io, where Organizers can sign in with their account, or create a new one.
This documentation is here to help support teams get a hold of this console.

DOCUMENT Related to V3.73

URL

• Production: https://backoffice.tixngo.io/
• Pre-production: https://backoffice-preprod.tixngo.io/
• Val: https://backoffice-val.tixngo.io/

0. Diverse

0.1 PROFILE PAGE - ACCOUNT

The profile page allows organiser to see the information liked with their account, such as company name, address and the api_key needed to do call the TIXnGO API.
This page is only accessible via the "ADMIN" account of the organizer and lets organizer manage their different accounts (ability to create/delete new accounts with specific role, see more in the Privilege section).

0.2 TIME IN THE CONSOLE

The Console display the Start Time (and all other time) in "Browser Time" so that the person using it sees it in the time zone they are in (offset is written in parentheses for StartTime).
The Mobile Application display the time as it was injected, which should be the local time of the Event (standard ticketing).
Example:
Lets say a Ticket is injected for an Event that starts the 2020-01-01 at 20:00 in Lausanne (UTC + 1) the time sent in the injection batch should be "2020-01-01T20:00:00+01". Imagine this event is organized by an English company based in London.
On the Mobile ticket in the app, one will see 2020-01-01 20:00 (as it is always display in the local time of the event).
On the Console the Support Team based in London (UTC) will see Start Time 2020-01-01 19:00 (their local browser time). The purpose of this is that the Support Team see correctly when the event (and other time) will start based on their local time, meaning they won't have to make time conversion every time they look at something.

1. TICKETS

1.1 TICKETS PAGE

The purpose of the Tickets page is to monitor every tickets that has been injected in the TIXnGO system in real-time. This view displays the Ticket ID, it's taxation number, barcode, current owner name / email, initial owner name / email and status, as well as the related event's name, start time and file ID and it can be exported to an excel sheet, using the excel button.
One can search for a specific ticket(s) using the search field at the top of the page (black rectangle in the screenshot example).
Clicking on a Ticket ID will redirect you to the Support → Ticket screen, showing much more information about one particular ticket (see Support section).
Clicking on the Event name will redirect you to the Event page for that specific Event.
Clicking on the Owner email will redirect you to the Support → Spectator screen, showing information about that specific spectator (see Support section).
The Action column is used to display information about the ticket such as Transfer rules, Main and Extra data (Ticket button) and allows Main and Extra data edition (Pencil button). Organizers can also delete ticket, deleted reason and deleted ticket visibility are required (Wastebasket button).
Clicking on Export Ticket Details to export ticket details data.

1.2 TICKETS STATUS DESCRIPTION

AdminTool statuses

• INJECTED
  Organizer: Ticket can be seen in the AdminTool as it was injected in TIXnGO system.
  Spectator: Does not have Ticket in his wallet yet,
  
  
• DOWNLOADED
  Organizer: Ticket can be seen in the AdminTool as DOWNLOADED.
  Spectator: Sees Ticket in his wallet yet.
  
  
• ACTIVATE
  Organizer: Ticket can be seen in the AdminTool as ACTIVATED.
  Spectator: Sees Ticket in his wallet and sees the QR code.
  
  
• ONLINE ACTIVATE
  Organizer: Ticket can be seen in the AdminTool as ONLINE ACTIVATED.
  Spectator: Sees Ticket in his wallet and sees the QR code.
  
  
• OFFLINE ACTIVATE
  Organizer: Ticket can be seen in the AdminTool as OFFLINE ACTIVATED.
  Spectator: Sees Ticket in his wallet and sees the QR code.
  
  
• MANUAL ACTIVATE
  Organizer: Ticket can be seen in the AdminTool as MANUAL ACTIVATED.
  Spectator: Sees Ticket in his wallet and sees the QR code.
  
  
• BLUETOOTH ACTIVATE
  Organizer: Ticket can be seen in the AdminTool as Bluetooth ACTIVATED.
  Spectator: Sees Ticket in his wallet and sees the QR code.
  
  
• DEACTIVATED
  Organizer: Ticket can be seen in the AdminTool as DEACTIVATED.
  Spectator: Sees Ticket in his wallet and do not the QR code.
  
  
• ASSIGNED
  Organizer: Ticket can be seen in the AdminTool as ASSIGNED.
  Spectator: Sees Ticket in his wallet and sees the assigned name on the ticket.
  
  
• PENDING
  Organizer: Ticket can be seen in the AdminTool as PENDING.
  Spectator: Transferrer sees Ticket in his wallet in the transfer screen. Transferre still does not see the ticket in his wallet

• PENDING_TRANSFER
  Organizer: Ticket can be seen in the AdminTool as PENDING_TRANSFER.
  Spectator: Transferrer sees Ticket in his wallet in the transfer screen. Transferre still does not see the ticket in his wallet

• PENDING_P2P_RESALE
  Organizer: Ticket can be seen in the AdminTool as PENDING_P2P_RESALE.
  Spectator: Transferrer sees Ticket in his wallet in the resale screen. Transferre still does not see the ticket in his wallet.

• PENDING_2MKT_RESALE (not yet applied)
  Organizer: Ticket can be seen in the AdminTool as PENDING_2MKT_RESALE.
  Spectator: #
• FAILURE
  Organizer: Ticket can be seen in the AdminTool as FAILURE.
  Spectator: Transferred can see ticket in his wallet. Transferred failed (either failed, rejected or cancelled)
  
  
• FAILURE_TRANSFER
  Organizer: Ticket can be seen in the AdminTool as FAILURE_TRANSFER.
  Spectator: Transferred can see ticket in his wallet. Transferred failed (either failed, rejected or cancelled)

• FAILURE_P2P_RESALE
  Organizer: Ticket can be seen in the AdminTool as FAILURE_P2P_RESALE.
  Spectator: Transferred can see ticket in his wallet. Transferred failed (either failed, rejected or cancelled)

• FAILURE_2MKT_RESALE (not yet applied)
  Organizer: Ticket can be seen in the AdminTool as FAILURE_2MKT_RESALE.
  Spectator: #

• TRANSFERRED
  Organizer: Ticket can be seen in the AdminTool as TRANSFERRED.
  Spectator: Transferrer do not see ticket anymore (only transfer history). Transferre sees the ticket in his wallet.

• RECEIVED

Organizer : #

Spectator : Ticket received = injected + app download and ticket visible in the app for the spectator (to confirm with Team)

• RESOLD_P2P_RESALE
  Organizer: Ticket can be seen in the AdminTool as RESOLD_P2P_RESALE.
  Spectator: Transferrer do not see ticket anymore (only resale history). Transferre sees the ticket in his wallet.

• RESOLD_2MKT_RESALE (not yet applied)
  Organizer: Ticket can be seen in the AdminTool as RESOLD_2MKT_RESALE.
  Spectator: #

• CONTROLLED
  Organizer: Ticket can be seen in the AdminTool as CONTROLLED.
  Spectator: Not applicable.
  
  
• DELETION PENDING
  Organizer: Ticket can be seen in the AdminTool as DELETION PENDING.
  Spectator: Not applicable.

• DELETED
  Organizer: Ticket can be seen in the AdminTool as DELETED.
  Spectator: Spectator does not sees ticket anymore (or greyed-out if show deleted ticket selected).

1.3 TICKETS INJECTION

The Tickets Injection page lets organizer inject new tickets providing the minimum required information for the ticket and event, as well as more detailed information such as the activation parameters, transfer rules and custom ticket details.
The injection can be done for a single ticket, which can be useful to create a few test tickets, or it can be done for multiple tickets at a time using a .CSV file.

For the complete list of injection variable, please take a look at the official documentation: https://developer.TIXnGO.io/pdf/TIXnGO-Injection-Doc.pdf
WARNING: All Dates must follow the RFC3339 standard for date & time.

1.3.1 CSV File Injection

The CSV file injection tab allows the organizer to inject up to 20'000 tickets at a time.
This page list the jobs that were sent by the organizer and its status for all of them. The uploaded CSV is downloadable as well as the output, explaining which ticket where injected and which were refused (with the error associated with it).
Failed jobs are also downloadable and the error provided on each format error that would be in the injection CSV.
Two templates are available, a minimal required fields template and a complete templates with all possible ticket fields to help with the CSV setup.
The CSV file must be UTF-8 encoded.
A full documentation is available here: https://developer.TIXnGO.io/pdf/TIXnGO-Injection-Doc.pdf

1.4. Tickets Bulk Update

The Bulk update page allows the organizer to update ticket details by CSV batch (Max 50 rows per batch).

The CSV template can be get by clicking CSV template button or Export Ticket Details button (in the Tickets page) .

Variable details 

The update result will be available in the OUTPUT column once the input file is submitted successfully.

WARNING: 

• The CSV delimiter must be ";".
• The Data format must be the same as the template gets from CSV template or Export Ticket Details.
• The maximum number of rows is 50.
• The output file will not be saved in the system

2. Support Screens

2.1 TICKET

The Support - Ticket page lets the organizer or support team look for in depth information about one specific ticket. It's easily reachable from the Tickets page by clicking on the ID of a particular ticket, or by searching for an ID or barcode in the Support - Ticket screen directly (Warning: As the page display information about only one ticket, the search result must be unique, if one only knows part of the information of a ticket, searching through the Tickets page then selecting the ticket might be the better way).
The information displayed on this screen is same as those in ticket page and more, includes:

• The ticket's Current Owner details, the Initial Spectator details as well as the ticket's Holder details (also called Guest), if there is one.
  - Current Owner: The Spectator currently owning the ticket, the ticket is inside his wallet (main applicant flag displayed).
  - Initial Spectator: The Spectator that was the first ever "Current Owner" of the ticket, the one the ticket was injected to by the Organizer. This will never change through the life of the ticket.
  - Ticket Holder: The person assigned to a ticket that is held by the "Current Owner". The name of the Ticket Holder will appear on the ticket.
• This screen also contains the Ticket Details (Main, Extra & Hidden) usually used for Seating detail and specifics to be display on the ticket.
• The ticket's Status History (all ticket status logs): injected, downloaded, activated(online, offline, Bluetooth, manual)/deactivates, assigned, pending(pending_transfer, pending_p2p_resale, pending_2mkt_resale), transferred success/failure (transfer/p2p_resale) , controlled & deletion_pending/deleted (deleted reason included) with Backend & Mobile timestamps
• The ticket's Transfer rules (editable).
• File Id: It's SecuTix number called "File ID" (ticket order number)
• The number "Total in File" = Total number of ticket with the same File ID (which is the ID of a SecuTix injection file)
• The number "Total Transferred in File" = the total number of ticket transferred with the same File Id. Here is the original JIRA:  Unable to locate Jira server for this macro. It may be due to Application Link configuration.

2.2 SPECTATOR

The Support - Spectator page lets the organizer or support team look for information about one specific spectator. It's accessible by clicking on a spectator's email address from any other page in the Console, or by searching for an email address, ticket ID, barcode or name (Warning: As the page display information about only one spectator, the search result must be unique, if one only knows part of the information, searching through the Tickets/Spectator page then selecting the email address might be the better way).
The information displayd on this screen includes:

• Spectator's detail, including email, first and last name, gender, birthdate, nationality, passport number, Id card number, phone number and country of residence.
• The spectator's Tickets list: all tickets currently owned by the spectator ('Downloaded' → appear inside Owner's wallet) + the ones that were deleted ('Downloaded' + 'Deleted' → do not appear inside Owner's wallet). This list contains the Event name, the Ticket ID, the Ticket's taxation number, its barcode, status, as well as the start time of the Event, the activation time of the Ticket (if there is one), the email address of the purchaser (= Initial Spectator) and the date and time the Ticket was injected. This list is filterable in two ways: All tickets currently in the spectator's wallet OR All tickets that have been at anytime in the spectator's wallet.
• The spectator's Mobile logs.
• The spectator's Communication logs with the ability to resend a specific communication. The content of the communication can be read with a click on the reason title.

3. EVENTS

3.1 EVENTS PAGE

The Events page allows organizer to have control over their different events. Specific events can be search by Event ID or Name.
The Events are ordered by Start Time (filters by startTime/endTime can be applied).
This page first displays the Preparation, Steward and Gate beacon information, so organizers can have a quick access to those keys.

The button "Export Event" (under title "Event List") allows Organizer to export all event details
The Events list shows every Event created by the organizer with their Ticket's status count (this gives the overview of the event with the total number of injected tickets, the total number of downloaded tickets, the number of tickets still pending (Pending after transferring), the total number of controlled tickets (Tickets that have been scanned by the staff). The action column lets the organizer:

• Update the event's information

  Variable Name	Variable Type	Value length	Variable usage/description
  Event Name	string	128 char	Name of the match
  Website URL	string	128 char	If specified then clickable URL displayed at the Ticket Detailed View
  Event Group Image URL	string	256 char	Display image as per URL on following ticket views: My Tickets - "Group Image"
  Event Group Name	string	128 char	Display name on following view: My Tickets - Event Group Name
  Ribbon Display Time	string	must follow RFC 3339 date format	Time at which a ribbon is displayed on the mobile app to notify spectator to turn on Bluetooth. This Ribbon Display Time is not converted in local browser time as we must set here the Time Zone
  Start Time	string	must follow RFC 3339 date format	Displays Match date and kick-off time at the Ticket View and Ticket Detailed View. This Start Time is not converted in local browser time as we must set here the Time Zone
  Expiration date	string	must follow RFC 3339 date format	Not displayed, this is the Time at which the Event Expires. This Expiration Time is not converted in local browser time as we must set here the Time Zone
  Time Zone	offset	must follow RFC 3339 date format	Time Zone offset for Start Time, Expiration Time & Activation Time of the Event
  Site	string	200 char	Site name displayed at the Ticket View and Ticket Detailed View under Address title
  City	city	200 char	City where the event takes place
  Line 1	string	200 char	line 1 of the address
  Line 2	string	200 char	line 2 of the address
  Line 3	string	200 char	line 3 of the address
  Country Code	string	200 char	country code for the address
  Region	string	200 char	region of the event
  Zip	string	200 char	zip code for the address
  Longitude	number	float	longitude of the event's location
  Latitude	number	float	latitude of the event's location
  Mobile App Id	string	256 char	Used as a key to display tickets only for the particular Event
  Ticket Image URL	string	256 char	Display image as per URL on following ticket views: Ticket View, Ticket Detailed View
  Remove Ticket Image URL	Boolean	Boolean	Enable the deletion of all tickets image URLs in that event.
  Transfer Group Id	string	256 char	Transfer rules can technically be different for every ticket. Organizer might want to chose to have different transfer rules for different types of ticket (ex: Adult, child, VIP, etc…). This GroupID is the Transfer rules group ID representing a group of transfer rules applied to certain tickets. If Organizers want to apply the same rules to every tickets, by default this groupID is set to the EventID and every ticket will be in this group.
  Max number of Ticket per receiver's Phone	integer	integer	Maximum amount of tickets per phone for this Transfer rules group id
  Max Resell Price increase (in %)	integer	smallint	Maximum profit (price increase in %) of the original ticket price for a resell between spectator. It is editable or used only if organizer resale setting is enabled
  Max number transfer per Phone	integer	integer	Total amount of transfers per Phone (-1 feature is disabled). Counter is increased for every new transfer, but decrease on a Return.
  Max number transfer per Ticket	integer	integer	Total amount of transfers per Ticket (-1 feature is disabled). Counter is increased for every new transfer, but decrease on a Return.
  Assign Limit	integer	integer	Upper bound amount of transfer before the Assign function is disable (-1 means unlimited)
  Allow Transfer	Boolean	Boolean	Enables or Disables transfer functionality for given match (Send menu item in the ticket view hidden or displayed)
  Allow Transfer after Activation	Boolean	Boolean	Enables or Disables transfer functionality for given match for Activated Tickets (Send menu item in the ticket view hidden or displayed)
  Allow Transfer after Control	Boolean	Boolean	Enables or Disables transfer functionality for given match for Controlled Tickets (Send menu item in the ticket view hidden or displayed)
  Allow Return To Organizer	Boolean	Boolean	Enables or Disable allow everyone to release ticket to resale. (More Details)
  Allow Return To Organizer For Initial Spectator	Boolean	Boolean	Enables or Disable only Initial Spectator can release ticket to resale.
  Resale Group Id	string	256 char	Resale rules can technically be different for every ticket. Organizer might want to chose to have different resale rules for different types of ticket (ex: Adult, child, VIP, etc…). This GroupID is the Resale rules group ID representing a group of resale rules applied to certain tickets. If Organizers want to apply the same rules to every tickets, by default this groupID is set to the EventID and every ticket will be in this group. It is editable or used only if organizer resale setting is enabled
  Allow Resell	Boolean	Boolean	Enables or Disables resale functionality for given match for all Tickets (Send menu item in the ticket view hidden or displayed) It is editable or used only if organizer resale setting is enabled
  Allow Resell after Activation	Boolean	Boolean	Enables or Disables resale functionality for given match for ActivatedTickets (Send menu item in the ticket view hidden or displayed) It is editable or used only if organizer resale setting is enabled
  Keep one Ticket Overall	Boolean	Boolean	Force ALL ticket wallet holders to keep at least 1 ticket per given Match
  Keep one Ticket at Injection	Boolean	Boolean	Force ticket wallet holder to whom tickets were originally injected to keep at least 1 ticket per given Match. E.g. all his transfer guests will be able to forward all the tickets they received
  The Resale & Purchase Agreement URL	string	512 char	The Resale & Purchase Agreement URL in P2P resale It is editable or used only if organizer resale setting is enabled
  Ticket Terms & Conditions URL	string	512 char	Ticket Terms & Conditions URL in P2P resale
  Resale Options	string	100 char	Support organizer define the resale price with three options A, B and C per Transfer Group Id: "Option A: Price range" [the resale price of this ticket is allowed by the event organizer to be resold between a minimum and a maximum] "Option B: Fixed price" [the resale price of this ticket is set by the event organizer] "Option C: Unlimited price" [the resale price of this ticket is allowed by the event organizer to be resold at any price] It is editable or used only if organizer resale setting is enabled
  Min resale price decrease	number	float	Enable when Resale option A is selected. Min resale price decrease (in % of the initial price) of the ticket to be resold It is editable or used only if organizer resale setting is enabled
  Max resale price increase	number	float	Enable when Resale option A is selected. Max resale price Increase (in % of the initial price) of the ticket to be resold It is editable or used only if organizer resale setting is enabled
  Specific resale price decrease/increase	number	float	Enable when Resale option B is selected. Specific resale price decrease/increase (in % of the initial price) of the ticket to be resold: Value > 0: Increase Value < 0: Decrease It is editable or used only if organizer resale setting is enabled
  Activation Id	string	50 char	Activation group ID. Different tickets could have different activation method, this group ID make the distinction between them.
  Activation Time	string	must follow RFC 3339 date format	Timestamp at which the tickets in the activation ID will be activated (following the given Activation Method). This Start Time is not converted in local browser time as we must set here the Time Zone
  Activation Method	string	online/offline	Define ticket activation method for this activation ID, can be online or offline. (Used only if a timestamp is given in Activation Time
  Barcode Size	string	key = 128 char; value = 128 char	Used to adjust QR code size in mm. Reflects both width and height. The value must between 10 and 32 (10 <= barcode size <= 32).
  Barcode Position	string	key = 128 char; value = 128 char	Used to adjust QR code position in case if QR code size smaller that smartphone screen width (center, left, right)
  Event Number	number	0 <= number <= 99	Display Event Number on mobile ticket if required
  Enable Covid Check	Boolean	Boolean	Enables or Disable COVID check functionality for given event
  TicketShop Resale URL	string	key = 128 char; value = 128 char	The URL of TicketShop resale
  Prohibited Items Image URL	string	key = 128 char; value = 128 char	Display Prohibited items image from this URL
  Prohibited Items Link	string	key = 128 char; value = 128 char	Makes Prohibited Items Image clickable when redirecting to this link (must provide Image URL)
  Sponsors Image URL	string	key = 128 char; value = 128 char	Display Sponsor image from this URL
  Sponsors Link	string	key = 128 char; value = 128 char	Makes Sponsors Image clickable redirecting to this link (must provide Image URL)
  Seat Map Image URL	string	key = 128 char; value = 128 char	Display Seat Map image from this URL
  Seat Map Link	string	key = 128 char; value = 128 char	Make Seat Map Image clickable redirecting to this link (must provide Image URL)
  Design Id	string	256 char	This Design Id representing a design applied to certain tickets in an Event
  Background Color	string	7 char hexadecimal color	The background color of the corresponding Design Id (Example: #bbccdd). If the background color is updated, all the tickets with the corresponding Design Id will be affected
  Ticket Resale Fixed Fee	number	float	For organizer could set amount fee for ticket of P2P resale It is editable or used only if organizer resale setting is enabled
  Ticket Resale Percent Fee	number	float	For organizer could set fee percent for ticket (calculating on resale price) of P2P resale It is editable or used only if organizer resale setting is enabled
  Fee Currency	string	3 char	For organizer could set currency of fee for ticket of P2P resale It is editable or used only if organizer resale setting is enabled

• See the security information (manual activation pin & Bluetooth instance ID for all activation groups)
• Create/Delete/Edit Questionnaires that can be send to every spectator attending the event.

3.2. Ticket Holder Questionnaire

The Ticket Holder Questionnaire popup allow organizer to ask questions related to operation or marketing to all ticket holders.
The organizer can decide to target or not the ticket wallet owners, who “opt-in” to marketing communication during the account creation, or through the in-app menu, for optional questions.
All their answers are collected, associated with their respective information and exported to XLS file by clicking Extract answers button.

Settings variables:

Question:

• Click "+" button (next to the language dropdown) to add a new question.
• Click "-" button to delete a question on respective row.
• Each question can be set as optional or mandatory. Some answers could be Expected as the single mandatory answer.
• Question can be edited as bold/italic/underline characters and hyperlink by selecting text to edit and click button in the tooltip (B, I, U, Link icon)

Type of answers:

• RADIO_BUTTON: box to choose between YES/NO.
• MULTIPLE_CHOICE: box to choose between A/B/C/... (with fields which could be added by clicking "+" button next to question content).
• FREE_TEXT: text answer.

4. SPECTATORS

4.1 SPECTATORS PAGE

The Spectator screen lets organizers see the list of Spectator owning tickets for one of their events. Spectator can be searched by email, first and last name, phone number, passport number, Id card number and SecuTix File ID.
This page displays a few information about spectators, such as their email, name, gender, account creation date and promo/tracking option.
Clicking on a spectator's email address will redirect to the Support→Spectator screen, showing more information about this specific spectator.

Actions column in the Spectator table allows organizer to log out a spectator from all his devices (kills all active sessions) in case the spectator needs to log in in a new device but could not log off others.

5. COMMUNICATIONS

5.1 COMMUNICATIONS PAGE

The Communications page allows organizers to view all communication logged in the TIXnGO system. Comm. logs can be search using the email address or phone number of the spectator, the type (email or push) the status (delivered or failed) and the transmission date.
This page displays the spectator's email (recipient of the communication), the reason of this communication, the transmission date, as well as the type and status of this communication.
Clicking on the reason title will show the communication content.
This page also contains a Resend button that lets Organizers resend all filtered communications. This action will trigger a prompt, asking the user to confirm before sending X notifications. This had to be used carefully has one can easily spam someone or even get blacklisted by Amazon Web Services.

5.2 NOTIFICATION CAMPAIGNS

The Notification Campaigns tab allows organizers to view all the notification campaigns they schedules, cancelled and sent. The campaigns can be searched by name, content language and the table displays the campaign ID, name, created date, scheduled date, status (scheduled, canceled or sent), the number of impacted spectators, successfully sent and failed notifications (all those numbers are updated after the campaign is sent as they come from reporting).
Clicking on the Campaign Name will open a popup box displaying the campaign's contents in all languages.
From this table one can update or cancel a scheduled campaign and rescheduled a cancelled campaign.
A download button will appear once the campaign has been triggered, allowing the user to download a report containing the spectator's email address and the status of the notification sent to him.
New campaign can also be created from the Schedule Campaign button.

In order to Schedule a new campaign one must select the Mobile App Id to which the campaign is going to be sent, provide a Name and setup a Date at which the campaign will be sent (time zone is configurable).
Filters work in this way: Mobile App Id defines which app is affected with the campaign. Event filters on the list of spectator that have tickets for that event, if none is selected, then campaigns targets all spectator having the Mobile App. On can also upload a CSV file of emails (e.g. input every emails in an Excel sheet under one column and export it to CSV), those email are used as a second filter, e.g. All users having ticket for the Event and are in the provided email list.

The system only checks if the spectator has the NotificationTokenID connected with AppID to send the notification. Therefore, the user who hasn't downloaded or registered an account won't be able to receive any notifications.

A default language must be selected from the dropdown list of supported languages. Notification title and content can be setup for all supported languages, if let blank the template is not used in the campaign. (e.g. if one supports EN and FR but only want to schedule this campaign in English, leave the French line blank).

While editing a campaign, if the text "CSV already uploaded" and the button "Download here" is visible, that means the CSV file the user previously input is still present and will be used as filter unless he uploads a new one.

6. TRANSACTIONS

6.1 TRANSACTIONS PAGE

The Transactions page allows organizers to view all ticket's transactions logged in the TIXnGO system. Transactions can be search using their transaction hash, their date, type or status.
This page displays information about the transaction such the date, the ticket ID, the sender and receiver if it exists, the transaction type, status and hash, as well as the reason if it exists (only for transfers).
Clicking on the ticket ID will redirect to the Support→Ticket screen for this ticket.
Clicking on the sender or recipient email will redirect to the Support→Spectator screen for this spectator.

7. PENDINGS

7.1 PENDINGS PAGE

The Pendings page allows organizers to view all "Pendings Tickets" (tickets where the transfer was initiated but the recipient did not yet sing-in to the app and loaded the tickets). Pendings can be search using the ticket ID, the date or the recipient registration source (account was created in TIXnGO system and user has the Mobile application or not yet: "Mobile App" or "External").
This page displays information about the Pendings Tickets, such as the ID, the taxation number, the event ID and name, the sender and recipient emails, the registration source and the date and time of the initiation of transfer.
Clicking on the Ticket ID will redirect to the Support→Ticket screen.
Clicking on the event ID or name will redirect to the Event screen.
Clicking on the sender or recipient will redirect to the Support→Spectator screen.

8. MOBILE LOGS

8.1 MOBILE LOGS PAGE

The Mobile Logs page lets the organizer see all logs from the mobile app (for the tickets injected on their mobile app). The logs can be searched by spectator's email, message content, app name (e.g. io.TIXnGO.app is the generic TIXnGO app), log level (i = info, e = error, w = warn), by platform (operating system), or by date.
The information displayed on this page contains the following: Log level, Spectator's email, action that was logged (e.g. authentication, ticket activation, etc...), the content of the logged message, the app name and version, the spectator's devise model, the platform (OS) and the date and time. All this information is mostly useful for debugging purposes.
Clicking on the spectator's email will redirect to Support→Spectator screen.

9. SETTINGS

9.1 SETTINGS PAGE

The Settings page allows the organizer to handle different app settings, app features, organizer settings, as well as translation option such as email and push notifications in different languages.

9.1.1 Application Settings

9.1.2 Application Features

9.1.3 Organizer Settings

9.1.3 Multilingual Settings

10. CHARTS

10.1 CHARTS PAGE

The Charts page is a new feature in the TIXnGO system (currently still under development), that shows organizer a graphical representation of the life cycle of their tickets, per event. This feature makes use of our Machine Learning algorithm to give trust scores to each user and detect fraudulent behavior.

What is the Spectators Behavior Analysis?

TIXnGO works everyday to improve security and reduce fraud in your events. The spectator behavior analysis is a Machine Learning tool developed by TIXnGO that classifies the actions of spectators during an event. Its purpose is to provide organizers with a deeper understanding of tickets life within their events and to help detecting users that might need monitoring.

How does it work?

This tool uses an ensemble of Machine Learning models and classifies regularly each spectator's behavior based on his transfers activity in every event where tickets have been injected. The Charts tab allows you to see an almost real-time representation of your events. This functionality coupled with our Blockchain technology, grants you the insurance to see who's in possession of your tickets at all times. This representation comes with a classification of spectators to help you identify users that might act in an unwanted way.

Disclaimer

Please bear in mind that this tool is an ongoing project that will improve upon time and data. Furthermore, the model used in the classification runs under the assumption that some kind of undesirable behavior will exist in the event. This implies that the resulting classification might not be relevant if every user acts with respect to the terms of use. The same applies for events with a very small amount of spectators.

How to read it ?

The color coded nodes represents users with tickets. The label on the left side explains the behavior for each color.
Green nodes are spectator with an Adequate Behavior, yellow ones are more dubious, oranges behave in a way we would prefer to avoid and red nodes are clearly bad behavior.
The size of nodes represents the inverse of trust score.

11. REPORTS

11.1 REPORTS PAGE

The Reports page allows organizer to generate a report of ticket statuses for any of their event. For now the reporting tool is limited to:

• Mobile Tickets Per Status subdivided per price category

12. QUESTIONNAIRE REPORT

The questionnaire report page is a new feature used to dig into the responses of a questionnaire. The goal is to offer the organizer the possibility to gain quick insights without having to look at an annoying CSV file.

The tool can be used even if there are no open-ended (free text) questions in the questionnaire (hence no natural language processing) since it will also help to gain insights about the closed questions (multiple-choice, radio-button).

ADDENDUM

1. Privileges on the AdminTool:

Few definitions:

1. Read privileges means ability to view a given page or a given information on the AdminTool
2. Create privileges means ability to create a new information on the AdminTool. Like create a ticket using the AdminTool
3. Update privileges means ability to update an existing information on the AdminTool. Like update ticket details, update match details
4. Delete privileges means ability to delete an existing information on the AdminTool. Like delete a ticket
5. Search privileges means ability to execute a search on the AdminTool
6. Export privileges means ability to export data from AdminTool
7. execute: ability to execute an action (such as: send communications).

Pre defined roles:

1. admin-user - AU: has all the privileges listed above.
2. support-user SU: has limited privileges to the AdminTool
3. basic-user BU: has only the ability to view information using the AdminTool

More details:

• The main user will be created manually by TIXnGO and provided to the organizer.
• The admin user will have the ability to create other users.
• Only 1 user can be admin. 

Table of roles: