#3-Data Mapping & Field Mapping Rules

Data mapping tells Novus where information should go when a supported integration sends data to another service.

For example:

Novus Ticket ID

→ Google Sheets: Ticket ID

Ticket Owner

→ Google Sheets: Member

Ticket Category

→ Google Sheets: Category

Without mapping, Novus may know the information but the integration does not know where that information belongs in the destination.

Understanding Source and Destination

Every basic mapping has two sides:

Source

The information coming from Novus.

Destination

Where that information should be placed.

For example:

Source	Destination
Ticket ID	Ticket ID
Ticket Owner	Discord Member
Ticket Category	Support Type
Ticket Status	Status

The source and destination names do not need to be identical.

Example

Suppose Novus calls a field:

Ticket Owner

but your Google Sheet uses:

Discord User

You can map:

Ticket Owner

→ Discord User

The destination does not need to use Novus' original field name.

Types of Mapping Sources

Depending on the workflow and integration, mapping sources may come from several places.

Common examples include:

• Ticket system fields
• Ticket Form responses
• Category information
• Resolution information
• AI-generated information
• Staff-related information
• Dates and timestamps
• Static values

Understanding the source type makes larger mappings easier to manage.

System Fields

System fields are values created or maintained by the Novus workflow rather than manually entered by the member.

Examples may include:

• Ticket ID
• Ticket Owner
• Ticket Category
• Created At
• Closed At
• Ticket Status
• Escalation Status
• Handler
• Resolution
• AI Summary

These are useful for operational tracking.

Example System Field Mapping

A Google Sheet contains:

Ticket ID	Member	Category	Created At	Status

Mapping:

Novus Source	Google Sheets Column
Ticket ID	Ticket ID
Ticket Owner	Member
Ticket Category	Category
Created At	Created At
Ticket Status	Status

Ticket Form Fields

Ticket Forms provide information entered by the member during ticket creation.

For example, a Technical Support form may contain:

Issue Type

Problem Description

Error Message

These fields can be useful mapping sources when the enabled integration supports Ticket Form data.

Example Form Mapping

Novus Source	Google Sheets Column
Form: Issue Type	Issue Type
Form: Problem Description	Problem
Form: Error Message	Error

This allows information collected during ticket creation to immediately become structured data.

System Fields and Form Fields Together

You can combine both types.

For example:

Novus Source	Destination
Ticket ID	Report ID
Ticket Owner	Reporter
Form: Bug Title	Title
Form: Description	Description
Form: Affected Area	Component
Ticket Status	Status
Resolution	Resolution
Created At	Reported At

This is useful for Bug Reports and applications.

Static Values

Some integrations may benefit from values that do not come directly from the ticket.

These are commonly called static values.

For example:

Source

Static value: Discord

→

Destination

Source

A resulting row might contain:

Ticket ID	Member	Source
NOVUS-1042	PlayerOne	Discord

Static-value support depends on the mapping capabilities available in the enabled integration.

Why Static Values Are Useful

Suppose the same Google Sheet receives records from:

• Discord
• Website
• Email
• Manual staff entries

A static value can help identify the origin.

For example:

Novus Workflow

→ Discord

Website Workflow

→ Website

This makes reporting easier.

Category-Specific Mapping

Different Ticket Categories often require different data.

For example:

Technical Support

needs:

• Issue Type
• Error Message
• Problem Description

while:

Streamer Application

needs:

• Platform
• Channel
• Schedule

Trying to force both into exactly the same mapping may create unnecessary empty columns.

Example Technical Mapping

Destination: Technical worksheet

Source	Column
Ticket ID	Ticket ID
Ticket Owner	Member
Form: Issue Type	Issue
Form: Problem Description	Description
Form: Error Message	Error
Ticket Status	Status
Resolution	Resolution

Example Streamer Mapping

Destination: Streamers worksheet

Source	Column
Ticket ID	Application ID
Ticket Owner	Discord User
Form: Streamer Name	Name
Form: Platform	Platform
Form: Channel URL	Channel
Form: Schedule	Schedule
Ticket Status	Status

The two workflows use different destination structures because they solve different problems.

Shared Fields Across Categories

Even when categories use different mappings, some fields can remain consistent.

For example:

• Ticket ID
• Ticket Owner
• Category
• Status
• Created At
• Closed At

Keeping common operational fields consistent makes cross-category reporting easier.

Recommended Common Field Names

For ticket-related Sheets, consider consistently using:

Ticket ID

Member

Category

Status

Created At

Closed At

Then add category-specific fields after them.

For example:

Ticket ID	Member	Category	Status	Created At	Issue Type	Resolution

Unique Keys

A unique key identifies one specific record.

For most native ticket workflows, the best candidate is:

Ticket ID

For example:

NOVUS-1042

A unique key becomes especially important when an integration needs to update an existing record.

Why Unique Keys Matter

Suppose your Google Sheet contains:

Ticket ID	Status
NOVUS-1041	Closed
NOVUS-1042	Open
NOVUS-1043	Escalated

When Ticket NOVUS-1042 is resolved, the integration needs to know which record should change.

Using Ticket ID allows the workflow to identify:

NOVUS-1042

and update its status.

Do Not Use Display Name as a Unique Key

Avoid:

Unique Key = Discord Display Name

Two members may have similar names, and members can change their display names.

For example:

Dragon

could later become:

DragonRF

The underlying support record should not become impossible to identify because of a display-name change.

Discord Channel ID as a Fallback

In some external-ticket workflows where a native Novus Ticket ID is unavailable, a stable Discord Channel ID may be useful as a reference when the integration exposes it.

For example:

Channel ID

→ External Record ID

Do not assume every external ticket provider exposes its own Ticket ID to Novus.

Create Behavior

A Create operation means:

Make a new destination record.

For example:

Ticket created:

NOVUS-1042

Google Sheets:

Ticket ID	Status
NOVUS-1042	Open

This is usually appropriate when the ticket first enters the integration workflow.

Update Behavior

An Update operation means:

Find an existing record and change selected information.

For example:

Ticket becomes resolved.

Find:

Ticket ID = NOVUS-1042

Then update:

Status = Resolved

Resolution = Launcher configuration corrected

This keeps one primary record for the ticket.

Create vs Update Example

Ticket Created

Create:

Ticket ID	Status	Resolution
NOVUS-1042	Open

Ticket Escalated

Update:

Ticket ID	Status	Resolution
NOVUS-1042	Escalated

Ticket Resolved

Update:

Ticket ID	Status	Resolution
NOVUS-1042	Resolved	Launcher configuration corrected

Ticket Closed

Update:

Ticket ID	Status	Resolution
NOVUS-1042	Closed	Launcher configuration corrected

The ticket remains one record.

One Row Per Ticket

For normal ticket tracking, the recommended model is:

One Ticket = One Row

This is easy to:

• Search
• Filter
• Sort
• Report
• Update

It also reduces unnecessary duplicates.

When Multiple Rows Are Appropriate

Multiple rows may be intentional when building an event log.

For example:

Ticket ID	Event	Time
NOVUS-1042	Created	10:00
NOVUS-1042	AI Responded	10:01
NOVUS-1042	Escalated	10:15
NOVUS-1042	Resolved	10:30

This is different from a normal Ticket Tracker.

Choose intentionally between:

Record Tracking

and:

Event Logging

Duplicate Prevention

Duplicate records can happen when the workflow repeatedly performs Create instead of finding and updating the existing record.

For example:

Incorrect:

Ticket ID	Status
NOVUS-1042	Open
NOVUS-1042	Escalated
NOVUS-1042	Resolved

Correct for a normal tracker:

Ticket ID	Status
NOVUS-1042	Resolved

Use a stable unique key whenever update behavior is required.

Optional Fields

Not every Ticket Form field needs to contain a value.

For example:

Error Code

may be optional.

If the member does not have an error code, the mapped destination may legitimately remain blank.

Do not treat every blank mapped value as an integration failure.

Recommended Optional Field Behavior

Suppose the form contains:

Error Message

Optional

Member leaves it blank.

Google Sheets can contain:

Ticket ID	Error Message
NOVUS-1042

This is cleaner than forcing:

N/A

unless your reporting process specifically requires a placeholder.

Missing Values vs Mapping Errors

These are different situations.

Missing Value

The mapping exists, but the source has no value.

Example:

Optional Error Code was not provided.

Mapping Error

The workflow cannot correctly resolve the configured source or destination.

Example:

Mapping still points to a Ticket Form field that was deleted.

Knowing the difference makes troubleshooting much easier.

Dropdown Fields

A dropdown usually produces one selected value.

For example:

Issue Type

Options:

• Launcher
• Client
• Login
• Website

Member selects:

Launcher

Mapped destination:

Launcher

This is straightforward for Google Sheets.

Single Choice Fields

Single Choice behaves similarly when one option is selected.

Example:

Frequency

• Once
• Sometimes
• Always

Member selects:

Always

Destination:

Frequency → Always

Multiple Choice Fields

Multiple Choice fields can contain several values.

For example:

Affected Platforms

Member selects:

• Windows
• Website

The destination may need to represent:

Windows, Website

or another supported multi-value format.

When planning a Google Sheets column, make sure it can accommodate more than one value.

Long Text Fields

Long Text fields may contain:

• Problem descriptions
• Reproduction steps
• Application explanations
• Additional information

These can be mapped to Google Sheets, but avoid putting extremely large conversations into them.

Ticket Form descriptions and full ticket transcripts are different types of information.

Data Transformation

Sometimes the source value is not exactly how you want it represented in the destination.

This is where data transformation may be useful when supported by the integration.

Conceptual examples include:

Boolean

true

→

Yes

or:

Category

TECHNICAL_SUPPORT

→

Technical

or:

Multiple Choice

["Windows","Website"]

→

Windows, Website

Transformation capabilities depend on the integration implementation.

Do Not Assume Transformation Exists

If your integration only supports direct source-to-destination mapping, do not design a workflow that requires complex transformations.

Start with the values Novus can reliably provide.

Advanced formatting can be added only when supported.

Date and Time Fields

Keep date formats consistent.

For example:

Created At

Closed At

Avoid mixing formats such as:

08/29/26

August 29, 2026

2026-08-29

inside the same reporting column.

Consistent formats make sorting and reporting easier.

Status Mapping

Define consistent statuses.

For example:

• Open
• AI Handling
• Staff Handling
• Escalated
• Resolved
• Unresolved
• Inactive
• Closed

Do not use several different words for the same state unless they have different meanings.

Resolved vs Closed

These should not automatically mean the same thing.

Resolved

means the concern was successfully completed.

Closed

means the ticket lifecycle ended.

A ticket may close because:

• It was resolved
• The member became inactive
• Staff manually closed it
• The issue could not be completed

If your reporting needs this distinction, use separate fields.

Recommended Outcome Mapping

Instead of only:

Status

you may use:

Field	Example
Status	Closed
Outcome	Resolved

Another ticket could contain:

Field	Example
Status	Closed
Outcome	Inactive

This preserves useful information.

Mapping AI Summary

When AI Summary is available for the applicable workflow, it can be useful for external reporting.

For example:

AI Summary

→ Google Sheets: Summary

However, do not use AI Summary as a replacement for structured fields such as:

• Ticket ID
• Status
• Category
• Dates

Structured information should remain structured.

Mapping Resolution

Resolution is especially useful for support reporting.

Example:

Resolution

User's launcher configuration was corrected and the client started successfully.

This can be mapped to:

Google Sheets

Resolution

It may also help staff identify recurring issues.

Resolution Is Not Automatically Knowledge

A mapped resolution stored in Google Sheets does not automatically become Knowledge Base content.

Knowledge still requires a reusable, verified support solution.

This separation prevents operational records from becoming unreviewed AI instructions.

Google Drive Destination Mapping

Google Drive mapping is usually less about spreadsheet columns and more about where a file should go.

For example:

Ticket Category

Technical Support

→

Drive Folder

/Novus Archive/Technical/

Another mapping:

Ticket Category

Payment Support

→

Drive Folder

/Novus Archive/Payment/

Dynamic Folder Concepts

Higher-volume environments may eventually use a structure based on multiple values when supported.

For example:

Category

Year

Month

could conceptually produce:

/Technical/2026/August/

Do not depend on dynamic folder generation unless the enabled Google Drive workflow explicitly supports it.

File Name Mapping

A stable file naming strategy might use:

Ticket ID

File Type

Result:

NOVUS-1042-transcript.html

This is safer than building filenames from member-provided descriptions.

Avoid User Input in File Names

A member could enter:

Problem Description

HELP!!! LOGIN / ACCOUNT ???

Using this directly as a filename can create:

• Invalid characters
• Very long filenames
• Privacy problems
• Inconsistent archives

Prefer system-controlled identifiers.

Google Sheets + Drive Shared Identifier

When using both services, map the same Ticket ID across them.

For example:

Google Sheets

Ticket ID: NOVUS-1042

Google Drive

Filename: NOVUS-1042-transcript.html

This allows staff to move between the tracker and archive confidently.

Example Complete Technical Mapping

Google Sheets Destination

Spreadsheet: Support Operations

Worksheet: Technical

Source	Destination
Ticket ID	Ticket ID
Ticket Owner	Member
Ticket Category	Category
Form: Issue Type	Issue Type
Form: Error Message	Error
Created At	Created At
Ticket Status	Status
Escalation Status	Escalated
Resolution	Resolution
Closed At	Closed At

Google Drive Destination

Category: Technical Support

Folder: /Novus Archive/Technical/

Filename: Ticket ID + transcript

Example:

NOVUS-1042-transcript.html

Example Complete Bug Report Mapping

Ticket Form

Bug Title

Description

Steps to Reproduce

Affected Area

Frequency

Google Sheets

Source	Destination
Ticket ID	Report ID
Ticket Owner	Reporter
Form: Bug Title	Title
Form: Description	Description
Form: Steps to Reproduce	Steps
Form: Affected Area	Component
Form: Frequency	Frequency
Ticket Status	Status
Resolution	Resolution

Google Drive

Folder: /Novus Archive/Bug Reports/

Archive: Ticket transcript when enabled

This creates a structured bug record plus a detailed archive.

Example Guild Application Mapping

Ticket Form

Guild Name

Guild Leader

Active Members

Active Schedule

Additional Information

Google Sheets

Source	Destination
Ticket ID	Application ID
Ticket Owner	Discord Contact
Form: Guild Name	Guild
Form: Guild Leader	Leader
Form: Active Members	Members
Form: Active Schedule	Schedule
Ticket Status	Status

Google Drive

Folder: /Novus Archive/Applications/Guilds/

This makes the workflow easier for staff to review.

Example Streamer Application Mapping

Ticket Form

Streamer Name

Platform

Channel URL

Schedule

Additional Information

Google Sheets

Source	Destination
Ticket ID	Application ID
Ticket Owner	Discord User
Form: Streamer Name	Streamer
Form: Platform	Platform
Form: Channel URL	Channel
Form: Schedule	Schedule
Ticket Status	Status

Google Drive

Folder: /Novus Archive/Applications/Streamers/

Mapping Sensitive Data

Not every available field should be exported.

Before mapping a field, ask:

Does the destination actually need this information?

If not, leave it unmapped.

This is particularly important for:

• Payment Support
• Account Support
• Administrative concerns
• Private applications

Avoid Mapping Secrets

Never intentionally map:

• Passwords
• OTP codes
• Authentication tokens
• Recovery codes
• API keys
• Private credentials

These should not be requested through normal Ticket Forms in the first place.

Mapping Changes Require Testing

If you modify:

Ticket Form

review:

Integration Mapping

If you modify:

Google Sheet

review:

Integration Mapping

If you modify:

Drive Folder Structure

review:

Integration Mapping

These systems depend on each other.

Example Form Change

Original field:

Guild Members

Mapped to:

Member Count

Later you replace the form field with:

Active Members

The old mapping may no longer represent the new source correctly.

Review mappings after form changes.

Example Sheet Change

Original column:

Discord Member

Later renamed:

Applicant

Review whether the integration mapping still points to the intended destination.

Do not assume external structure changes are automatically understood.

Mapping Validation

Before production use, validate every important mapping.

For each field, verify:

Source exists

↓

Source contains expected value

↓

Destination exists

↓

Value reaches correct destination

↓

Result has expected format

This catches most mapping problems.

Test With One Record

Start with one realistic test ticket.

For example:

Ticket ID: NOVUS-TEST-001

Category: Technical

Issue Type: Launcher

Status: Open

Confirm the destination.

Then continue the ticket and test updates.

Test the Full Record Lifecycle

A strong mapping test should include:

Creation

Status: Open

Escalation

Status: Escalated

Resolution

Outcome: Resolved

Closing

Status: Closed

Closed At: populated

Verify that the same record behaves as intended throughout the lifecycle.

Common Problem — Wrong Source

Symptom: Column is blank.

Example:

Mapping expects:

Form: Error Message

but the active Ticket Form uses:

Error Code

Review the actual source field.

Common Problem — Wrong Destination

Symptom: Data appears in an unexpected column.

Check:

Novus Source

→ Configured Destination

Do not rely only on column position.

Common Problem — Duplicate Records

Symptom: Same Ticket ID appears repeatedly.

Check whether the workflow is using:

Create

instead of:

Update

when processing later ticket events.

Common Problem — Old Mapping

Symptom: Mapping worked before a configuration change.

Check whether someone changed:

• Ticket Form
• Ticket Category
• Spreadsheet
• Worksheet
• Column
• Drive Folder
• Connected account

Integration issues often originate from configuration changes outside the mapping itself.

Common Problem — Missing Optional Data

Symptom: Some rows contain blank values.

First determine whether the field is optional.

A blank optional value may be completely valid.

Do not treat it as a failure unless the workflow requires the field.

Common Problem — External Ticket Missing Fields

External ticket providers may not expose the same structured information as Novus In-House Ticketing.

For example, a third-party ticket may not provide a native Novus Ticket Form response or Novus Ticket ID.

Do not map fields that do not reliably exist in that workflow.

Recommended Mapping Strategy

For most configurations:

Step 1: Map Ticket ID.

Step 2: Map Ticket Owner.

Step 3: Map Ticket Category.

Step 4: Map Status.

Step 5: Map Created/Closed dates.

Step 6: Add necessary Ticket Form fields.

Step 7: Add Resolution.

Step 8: Add optional AI or staff information.

Step 9: Test create/update behavior.

Step 10: Add Google Drive archiving if required.

Start with core data before adding advanced fields.

Recommended Mapping Checklist

Before publishing an integration:

• Source fields exist.
• Destination fields exist.
• Ticket ID is used where possible.
• Unique key is stable.
• Create behavior is correct.
• Update behavior is correct.
• Duplicate records are prevented.
• Optional fields can remain blank.
• Dropdown values map correctly.
• Multiple Choice values are handled correctly.
• Long Text fields fit the destination purpose.
• Status values are consistent.
• Resolved and Closed are distinguished when necessary.
• Sensitive fields are excluded.
• Form changes have been reviewed.
• Sheet changes have been reviewed.
• Drive folder changes have been reviewed.
• External-ticket limitations are considered.
• One complete test record has passed.
• The same Ticket ID can be located across connected systems.

Keep Mapping Simple

The best mapping is not necessarily the one with the most fields.

A good mapping answers:

What information does this destination actually need?

For a support tracker, that might only be:

Ticket ID

Member

Category

Status

Resolution

Created At

Closed At

Everything else should be added because it serves a clear purpose.

Next Step

Next we can continue with Integration Triggers & Automation Workflows.