#13-Native Ticket Forms, Fields & Data Mapping

Ticket Forms allow Novus to collect important information before a native ticket conversation begins.

Instead of opening an empty ticket and asking several basic questions one by one, you can collect the most important details immediately.

The current native ticket implementation supports optional forms with up to 5 fields, including:

• Short Text
• Long Text
• Dropdown
• Single Choice
• Multiple Choice

A well-designed Ticket Form can make support faster for both members and staff.

Why Use Ticket Forms?

Forms are useful when the same information is normally requested at the start of every ticket.

For example, Technical Support may repeatedly ask:

• What problem are you experiencing?
• What error are you seeing?
• Where does the problem happen?
• What troubleshooting have you already tried?

Instead of asking these questions after the ticket opens, a form can collect them during ticket creation.

Forms Should Reduce Questions

A good form should reduce repetitive conversation.

It should not create additional work for the member.

For example, if the form already asks:

What error message are you receiving?

Novus AI should not immediately ask:

What error message are you receiving?

unless the original answer is incomplete or unclear.

Ticket Form vs AI Conversation

The form provides initial structured context.

The AI conversation handles:

• Clarification
• Follow-up questions
• Troubleshooting
• Knowledge retrieval
• Escalation
• Resolution

Forms should not attempt to replace the entire support conversation.

Choosing the Right Field Type

Different information is easier to collect using different field types.

Use the field type that matches the kind of answer you expect.

Short Text

Use Short Text for concise information.

Examples:

• Character Name
• Transaction Reference
• Application Name
• Error Code
• Website URL
• Device Model

Avoid using Short Text for questions that require a detailed explanation.

Example Short Text Field

Label

Exact Error Code

Placeholder

Example: ERR_CONNECTION_01

Required

No

This gives the member a quick place to provide the error without forcing them to write a long response.

Long Text

Use Long Text when the member needs room to explain something.

Examples:

• Problem Description
• Steps to Reproduce
• Troubleshooting Attempted
• Reason for Application
• Additional Information

Example Long Text Field

Label

Describe the problem

Description

Explain what happened, what you expected to happen, and when the issue started.

Required

Yes

Dropdown

Use a Dropdown when the member should choose one value from a known list.

Examples:

Issue Type

• Launcher
• Client
• Website
• Login
• Connection
• Other

or:

Platform

• Windows
• Android
• iOS
• Web

Dropdowns improve consistency because members select from predefined values instead of entering different wording for the same thing.

Single Choice

Use Single Choice when the member must select exactly one option and the options are simple enough to display directly.

For example:

Is this issue happening right now?

• Yes
• No

or:

Concern Type

• Payment Pending
• Missing Item
• Verification
• Other

Multiple Choice

Use Multiple Choice when more than one option may apply.

For example:

Which areas are affected?

• Launcher
• Login
• Website
• Game Client
• Account Panel

This is useful when a problem is not limited to one system.

Required vs Optional Fields

Not every form field should be required.

Use Required when support cannot reasonably begin without the information.

Examples:

• Problem Description
• Application Name
• Bug Description

Use Optional when the information is useful but not always available.

Examples:

• Error Code
• Screenshot Reference
• Troubleshooting Attempted
• Transaction Reference

Too many required fields can make ticket creation frustrating.

Ask Only What You Need

A Ticket Form should contain the minimum information needed to start support.

Avoid creating forms that feel like long surveys.

Because the current form builder supports up to five fields, focus on the most useful questions.

Example Technical Support Form

A practical Technical Support form could use:

Field 1

Label

Problem Description

Type

Long Text

Required

Yes

Field 2

Label

Issue Type

Type

Dropdown

Options

• Launcher
• Client
• Installation
• Patch
• Login
• Connection
• Other

Required

Yes

Field 3

Label

Exact Error Message

Type

Short Text

Required

No

Field 4

Label

What have you already tried?

Type

Long Text

Required

No

This leaves room for another field if your support workflow needs it.

Example Bug Report Form

A Bug Report could use all five fields.

Field 1

Bug Title

Short Text

Field 2

Description

Long Text

Field 3

Steps to Reproduce

Long Text

Field 4

Affected Area

Dropdown

Options:

• Launcher
• Login
• Game
• Website
• Other

Field 5

How Often Does It Happen?

Single Choice

Options:

• Every time
• Sometimes
• Happened once

This gives staff structured information before they investigate.

Example Payment Support Form

A Payment Support category might use:

Field 1

Concern Type

Single Choice

Options:

• Payment Pending
• Payment Verification
• Missing Purchase
• Incorrect Purchase
• Other

Field 2

Transaction Reference

Short Text

Required: No

Field 3

Describe the concern

Long Text

Required: Yes

Avoid collecting full card information, passwords, OTP codes, recovery codes, or similar credentials.

Example Streamer Application Form

Field 1

Streamer Name

Short Text

Field 2

Platform

Dropdown

Options:

• Facebook
• YouTube
• Twitch
• TikTok
• Other

Field 3

Channel URL

Short Text

Field 4

Streaming Schedule

Long Text

Field 5

Programs Interested In

Multiple Choice

Options can depend on your community programs.

Example Guild Application Form

Field 1

Guild Name

Short Text

Field 2

Guild Leader

Short Text

Field 3

Estimated Active Members

Short Text

Field 4

Primary Play Schedule

Long Text

Field 5

Application Notes

Long Text

This provides enough information for staff to begin reviewing the application.

Form Naming

Use names that make the purpose obvious.

Good:

Technical Support Intake

Bug Report Form

Streamer Application

Poor:

Form 1

New Form

Support Data

Clear names make configuration easier when you have multiple categories.

Free and Premium Form Design

The current native implementation distinguishes between Free and Premium form behavior.

Free

One active Ticket Form across categories.

Premium

Separate forms per category.

This affects how you should design your forms.

Free Plan Use Case

If several categories must share one form, keep the form general enough to work across them.

For example:

Shared Support Form

Concern Type

Dropdown:

• General
• Technical
• Account
• Payment
• Other

Describe your concern

Long Text

Error or Reference

Short Text

Additional Information

Long Text

This can serve several support categories without being too specialized.

Premium Use Case

With separate category forms, each workflow can collect more relevant information.

For example:

Technical Support

→ Technical Intake Form

Payment Support

→ Payment Form

Bug Reports

→ Bug Report Form

Streamer Applications

→ Streamer Application Form

This provides cleaner data and reduces irrelevant questions.

What Is Data Mapping?

Data mapping connects information collected by Novus to another destination.

For example:

Novus Form Field

Bug Title

↓

Google Sheets Column

Title

or:

Ticket Category

Technical Support

↓

Google Drive Folder

/Technical Support/

The purpose of mapping is to tell the system:

This source data belongs in this destination.

Why Consistent Field Names Matter

Mapping becomes easier when form fields use consistent names.

For example, avoid using:

Character

in one form,

IGN

in another,

and:

Player Name

in a third

if they all mean the same thing.

Where possible, choose one consistent field name.

For example:

Character Name

This makes reporting and future integrations easier.

Google Sheets Mapping Use Case

Google Sheets works well for structured ticket information.

For example, you may want every completed Bug Report recorded in a spreadsheet.

A sheet might contain:

Google Sheets Column	Novus Source
Ticket ID	Native Ticket ID
Reporter	Ticket Owner
Category	Ticket Category
Bug Title	Form: Bug Title
Description	Form: Description
Steps	Form: Steps to Reproduce
Area	Form: Affected Area
Created At	Ticket Created Date
Status	Final Ticket Status
Resolution	Resolution Summary

This creates a searchable structured history of reports.

Example Mapping Configuration

Conceptually, the mapping might look like:

Destination

Google Sheets

Spreadsheet

Bug Reports

Worksheet

Open Reports

Mappings

Ticket ID → Report ID

Ticket Owner → Reporter

Form.Bug Title → Title

Form.Description → Description

Form.Steps to Reproduce → Steps

Ticket Status → Status

The exact interface may depend on the integration implementation available in your Novus deployment.

Static vs Dynamic Values

Not every mapped value must come directly from a form.

Some values may come from the ticket itself.

For example:

Dynamic

Ticket Owner

Ticket ID

Created Date

Closed Date

Ticket Category

Resolution

Form Data

Bug Title

Issue Type

Application URL

Transaction Reference

Combining both produces much more useful records.

Example Application Sheet Mapping

Suppose you want Streamer Applications stored in Google Sheets.

Your sheet could contain:

Sheet Column	Source
Application ID	Ticket ID
Discord Member	Ticket Owner
Streamer Name	Form: Streamer Name
Platform	Form: Platform
Channel	Form: Channel URL
Schedule	Form: Streaming Schedule
Created	Ticket Created Date
Status	Ticket Status
Review Result	Final Resolution

This allows staff to use the spreadsheet as an application tracker.

Example Guild Application Sheet

Possible columns:

Column	Source
Ticket ID	Ticket ID
Guild Name	Form: Guild Name
Guild Leader	Form: Guild Leader
Members	Form: Estimated Active Members
Schedule	Form: Primary Play Schedule
Discord User	Ticket Owner
Status	Ticket Status
Notes	Resolution Summary

This can reduce manual encoding by staff.

Mapping Ticket Categories to Different Sheets

Not every ticket type needs to use the same spreadsheet.

For example:

Bug Report

→ Spreadsheet: Development Reports

Streamer Application

→ Spreadsheet: Community Applications

Guild Application

→ Spreadsheet: Community Applications

Payment Support

→ Spreadsheet: Transaction Support

This keeps unrelated information separated.

Mapping to Different Worksheets

You may also use one spreadsheet with several worksheets.

For example:

Spreadsheet

Support Operations

Worksheets:

• General
• Technical
• Payment
• Bugs
• Applications

Then map each Ticket Category to the appropriate worksheet.

Example

Technical Support

→ Support Operations / Technical

Payment Support

→ Support Operations / Payment

Bug Report

→ Support Operations / Bugs

This is useful if staff prefers one central spreadsheet.

Status Mapping

Ticket status is especially useful for reporting.

Possible values may conceptually include:

• Open
• Active
• Escalated
• Resolved
• Closed
• Inactive

Your spreadsheet can use these values to track ticket progress.

Do not treat Inactive as Resolved unless the issue was actually confirmed as fixed.

Updating Existing Rows

A useful integration design is to keep one row per ticket.

For example:

When created:

Status

Open

Later:

Status

Escalated

Then:

Status

Resolved

Finally:

Closed At

is populated.

This is usually more useful than creating a completely new row every time something changes.

Ticket ID as a Mapping Key

A Ticket ID is useful as the unique identifier for spreadsheet synchronization.

For example:

NOVUS-1042

can identify the same ticket even if other values change.

This allows integrations to update the correct spreadsheet row instead of creating duplicates.

Google Drive Mapping Use Case

Google Drive is better suited for files rather than spreadsheet-style structured fields.

Examples include:

• Full ticket transcripts
• Ticket summaries
• Exported reports
• Attachments
• Archived ticket records

Example Google Drive Folder Structure

You could use:

Novus Tickets

→ 2026

→ Technical Support

→ NOVUS-1042-transcript.html

Another possible structure:

Novus Tickets

→ Technical Support

→ 2026

→ August

→ NOVUS-1042.html

Choose a structure that will remain understandable as your archive grows.

Ticket Category to Folder Mapping

A simple Drive mapping could be:

Ticket Category	Google Drive Folder
General Support	/Novus Tickets/General/
Technical Support	/Novus Tickets/Technical/
Payment Support	/Novus Tickets/Payment/
Bug Reports	/Novus Tickets/Bugs/
Applications	/Novus Tickets/Applications/

This keeps archives organized automatically when the integration is available.

Date-Based Folder Mapping

Large communities may want another level of organization.

For example:

Technical Support

↓

2026

↓

08-August

↓

Ticket transcript

This can make long-term archives easier to browse.

File Naming

Use predictable filenames.

For example:

NOVUS-1042-technical-support.html

or:

NOVUS-1042-transcript.html

Avoid filenames containing excessive member-provided text because:

• Names may be very long
• Special characters may cause problems
• Members may edit their display names
• Sensitive information could accidentally appear in filenames

Ticket IDs are more stable.

Google Sheets and Drive Together

Google Sheets and Google Drive complement each other.

A complete ticket archive could use:

Google Sheets

Stores the searchable index.

Google Drive

Stores the full transcript.

For example, the spreadsheet row could contain:

Ticket ID	Category	Status	Transcript
NOVUS-1042	Technical	Resolved	Drive File

The exact ability to insert Drive references depends on the enabled integration.

Example Full Support Mapping

Consider this workflow:

Member opens Technical Support

↓

Form collects:

• Issue Type
• Error Message
• Description

↓

Native ticket opens

↓

Novus AI troubleshoots

↓

Staff takes over if needed

↓

Issue resolved

↓

Ticket closes

↓

Google Sheets

updates:

• Ticket ID
• Member
• Issue Type
• Status
• Resolution
• Closed Date

↓

Google Drive

stores:

• Full transcript
• Optional summary

↓

Knowledge Base Review

checks whether the verified solution should become reusable knowledge

Each destination serves a different purpose.

Sheets Is Not the Knowledge Base

Do not confuse operational ticket reporting with AI Knowledge.

A Google Sheet containing ticket history is not automatically appropriate as AI Knowledge.

For example:

Ticket 1042

Member had a launcher problem.

This is historical support data.

But:

Launcher Error 202: Replace the outdated configuration file with the current version.

may be reusable Knowledge if verified and approved.

Knowledge should contain information Novus can safely reuse when answering future members.

Drive Is Not the Knowledge Base

The same applies to transcripts.

A transcript is a record of what happened.

It may contain:

• Incorrect guesses
• Failed troubleshooting
• Member-specific information
• Private data
• Staff discussion
• Irrelevant conversation

Novus should not automatically treat an entire transcript as verified Knowledge.

The existing resolution workflow can analyze whether useful new Knowledge is actually recommended before staff adds it.

Data Privacy

Be careful when sending ticket data to external destinations.

Avoid exporting unnecessary sensitive information.

Examples include:

• Passwords
• Authentication codes
• Recovery codes
• Full payment credentials
• API keys
• Private tokens
• Unnecessary personal information

Collect and store only what your support process genuinely requires.

Payment Ticket Mapping

Payment-related tickets may require stricter mapping.

For example, your Sheets record may only need:

• Ticket ID
• Member
• Transaction Reference
• Concern Type
• Verification Status
• Staff Handler
• Closed Date

The full conversation may not need to be copied into a general operational spreadsheet.

Do Not Map Internal Staff Notes Unnecessarily

If a ticket includes internal information, do not automatically expose it to a destination accessible by more people.

For example:

Discord

Payment staff only

but:

Google Sheet

Everyone on the support team

could create an unintended privacy problem.

Integration permissions should match the sensitivity of the source ticket.

Missing Data

Mappings should also tolerate optional fields.

For example:

Transaction Reference

may not always be available.

The system should not require fake placeholder data simply to complete the mapping.

A blank optional value is preferable to incorrect information.

Avoid Duplicate Mappings

Do not map the same information repeatedly without a reason.

For example:

Ticket Owner

→ Member

and:

Ticket Owner

→ Discord Member

and:

Ticket Owner

→ User

inside the same sheet usually adds unnecessary duplication.

Keep your destination structure clean.

Recommended Naming Convention

For larger configurations, use consistent names.

For example:

Ticket Categories

General Support

Technical Support

Payment Support

Bug Report

Forms

General Support Intake

Technical Support Intake

Payment Support Intake

Bug Report Intake

Google Sheets Worksheets

General Support

Technical Support

Payment Support

Bug Reports

Google Drive Folders

General

Technical

Payment

Bugs

Consistency makes integrations easier to troubleshoot.

Troubleshooting a Mapping

If a ticket reaches the wrong destination, check the chain.

For example:

Bug Report Form

↓

Correct Ticket Category?

↓

Correct integration rule?

↓

Correct spreadsheet?

↓

Correct worksheet?

↓

Correct column mapping?

↓

Correct permissions?

Do not immediately rebuild the form if the actual problem is the destination mapping.

Testing Google Sheets Mapping

When the Sheets integration is available, use a test ticket.

Enter recognizable test values such as:

Bug Title

Test Mapping Issue

Area

Launcher

Then confirm that:

• The correct spreadsheet receives the record.
• The correct worksheet is used.
• Fields appear in the expected columns.
• No duplicate row is created unexpectedly.
• Optional fields remain optional.
• Status updates apply to the correct ticket record.

Testing Google Drive Mapping

Create and close a test ticket.

Verify that:

• The expected archive folder is used.
• The correct ticket file is created.
• Filename is understandable.
• The transcript belongs to the correct ticket.
• Private tickets are not exported to an unintended shared folder.
• Closing does not remove the Discord ticket before required processing completes.

Data Mapping Checklist

Before using forms and external mapping, confirm:

• The form collects only useful information.
• Field labels are clear.
• Required fields are genuinely necessary.
• Optional fields can remain empty.
• No secret credentials are requested.
• Field names are consistent.
• Each form is attached to the correct Ticket Category.
• Ticket Categories use consistent naming.
• Destination spreadsheet is correct.
• Destination worksheet is correct.
• Each source field maps to the intended column.
• Ticket ID is available as a stable identifier.
• Duplicate rows are avoided.
• Google Drive folder mappings are correct.
• Archive filenames are predictable.
• Sensitive categories use appropriate access controls.
• Transcripts are not treated automatically as Knowledge.
• Only verified reusable solutions enter the Knowledge Base workflow.

Next Step

Once your native ticket forms and data structure are configured, the next step is understanding what happens after a ticket is created and eventually closed.

Continue to Native Ticket Transcripts, Closing & AI Summary, where we'll cover native transcript destinations, per-category transcript overrides, ticket-owner copies, closing delays, AI-generated ticket summaries, inactive versus resolved outcomes, and practical archive workflows.