Integrations

#4-Integration Triggers & Automation Workflows

Learn how integration triggers determine when Novus sends, updates, or archives data. Understand common ticket lifecycle events, create and update actions, trigger timing, duplicate prevention, workflow sequencing, Google Sheets and Google Drive examples, and recommended automation patterns.

Updated 8/29/2026, 2:38:46 AM

Integration triggers determine when a workflow should run.

A mapping tells Novus:

What data should go where

while a trigger tells Novus:

When that action should happen

For example:

Trigger: Ticket Created

Action: Create a Google Sheets row

Another example:

Trigger: Ticket Closed

Action: Archive the ticket transcript to Google Drive

Together, triggers and mappings create an automation workflow.

Understanding Triggers

A trigger represents an event in the support lifecycle.

Common conceptual examples include:

Ticket Created
Ticket Updated
Ticket Escalated
Ticket Resolved
Ticket Closed
Form Submitted
Staff Takeover
Inactivity Closure

The exact trigger options available depend on the integration and Novus version enabled for your deployment.

Trigger vs Action

A trigger and an action are different.

Trigger

Something happens.

Example:

Ticket Created

Action

Novus performs an integration operation.

Example:

Create Google Sheets row

Combined:

Ticket Created

↓

Create Google Sheets row

Another Example

Ticket Closed

↓

Archive transcript to Google Drive

The trigger starts the workflow.

The action performs the work.

Basic Ticket Lifecycle

A normal support ticket may move through:

Created

↓

AI Handling

↓

Staff Handling

↓

Escalated

↓

Resolved

↓

Closed

You do not necessarily need an integration action for every stage.

Only automate events that provide useful external information.

Recommended Starting Point

For a basic support tracker, start with:

Ticket Created

→ Create row

Ticket Resolved

→ Update resolution

Ticket Closed

→ Finalize status and closed date

This is usually enough for useful reporting.

Ticket Created Trigger

The Ticket Created event is commonly used to create the external record.

Example:

Trigger

Ticket Created

Destination

Google Sheets

Action

Create Row

Fields

Ticket ID
Member
Category
Created At
Status

Result:

Ticket ID	Member	Category	Status
NOVUS-1042	PlayerOne	Technical	Open

Why Create the Record Early?

Creating the row when the ticket starts gives staff visibility into currently open tickets.

Without this, the Sheet may only contain completed tickets.

That may be fine for historical reporting, but it is less useful as an operational tracker.

Form Submitted Trigger

Some workflows may use a form submission as the important event.

For example:

Streamer Application Form Submitted

↓

Create Application Record

This can be useful when the form itself contains the information staff needs to review.

Ticket Updated Trigger

A Ticket Updated trigger may be useful when operational data changes.

Examples:

Status changes
Handler changes
Escalation changes
Form information is updated
Resolution information becomes available

However, avoid running unnecessary external writes for every small ticket activity.

Do Not Treat Every Message as an Update

A conversation may contain dozens or hundreds of Discord messages.

You usually do not want:

Member sends message

↓

Update Google Sheet

for every message.

This creates unnecessary integration traffic and provides little reporting value.

Use meaningful lifecycle changes instead.

Staff Takeover Trigger

If your integration exposes staff takeover as a trigger or status change, it can be useful for support operations.

Example:

Staff Takeover

↓

Update:

Handler Mode = Staff

or:

Status = Staff Handling

This helps distinguish tickets resolved entirely by AI from tickets requiring manual support.

Escalation Trigger

When a ticket requires additional staff attention, an escalation event can update external tracking.

Example:

Trigger

Ticket Escalated

Action

Update existing Google Sheets row

Values

Status: Escalated

Escalated: Yes

Example Escalation Record

Before:

Ticket ID	Status	Escalated
NOVUS-1042	Open	No

After escalation:

Ticket ID	Status	Escalated
NOVUS-1042	Escalated	Yes

The same ticket remains one row.

Ticket Resolved Trigger

Resolution is one of the most valuable integration events.

When a ticket is successfully resolved, the workflow can update:

Status
Outcome
Resolution
Resolved At
Handler

Example:

Ticket Resolved

↓

Find:

Ticket ID = NOVUS-1042

↓

Update:

Outcome: Resolved

Resolution: Launcher configuration corrected

Resolved Is Not Always Closed

A ticket can be resolved before the channel is actually closed.

For example:

Member: It's working now.

↓

Novus or staff identifies the concern as resolved.

↓

Closure confirmation or final processing occurs.

↓

Ticket is closed.

Because of this, Resolved and Closed can be separate triggers.

Ticket Closed Trigger

Ticket Closed is commonly used for finalization.

Example:

Trigger

Ticket Closed

Google Sheets

Update:

Status = Closed
Closed At = timestamp
Final Outcome = Resolved

Google Drive

Archive supported transcript file

This is a strong trigger for final archival operations.

Recommended Closing Sequence

When archives are required, a safe conceptual sequence is:

Closure Begins

↓

Gather Final Ticket Data

↓

Generate / Process Transcript

↓

Send Transcript to Configured Discord Destination

↓

Archive to Google Drive if enabled

↓

Finalize External Tracker

↓

Complete Channel Closing / Deletion

The exact processing sequence depends on the enabled Novus workflow.

Why Trigger Order Matters

Imagine the ticket channel is deleted before the archive workflow obtains the required ticket data.

The integration may no longer have everything needed to create a complete archive.

Actions that depend on ticket content should therefore be completed at the appropriate stage of the closing process.

Create and Update Actions

A common mistake is using Create for every trigger.

For example:

Ticket Created

→ Create row

Ticket Escalated

→ Create row

Ticket Resolved

→ Create row

Ticket Closed

→ Create row

This creates four records for one ticket.

Better Workflow

Use:

Ticket Created

→ Create

Then:

Ticket Escalated

→ Update

Ticket Resolved

→ Update

Ticket Closed

→ Update

Result:

One Ticket = One Row

Example Complete Lifecycle

Ticket Created

Ticket ID	Status	Escalated	Resolution
NOVUS-1042	Open	No

Ticket Escalated

Ticket ID	Status	Escalated	Resolution
NOVUS-1042	Escalated	Yes

Ticket Resolved

Ticket ID	Status	Escalated	Resolution
NOVUS-1042	Resolved	Yes	Launcher fixed

Ticket Closed

Ticket ID	Status	Escalated	Resolution
NOVUS-1042	Closed	Yes	Launcher fixed

This is usually easier to manage than four separate rows.

Unique Key Requirement

Update workflows require a reliable way to find the existing record.

Recommended:

Ticket ID

Example:

NOVUS-1042

The workflow can conceptually perform:

Find Ticket ID = NOVUS-1042

↓

Update row

Without a unique key, updates may create duplicates or modify the wrong record.

Trigger Filters

Not every trigger should apply to every Ticket Category.

For example:

Ticket Closed

could have different actions depending on category.

Technical Support

→ Update Support Sheet

→ Archive to Technical Drive folder

Payment Support

→ Update restricted Transaction Sheet

→ Archive to restricted Payment folder

Streamer Application

→ Update Applications Sheet

→ Archive to Community folder

This is where category filtering becomes important.

Category-Based Workflow Example

Trigger

Ticket Closed

Condition

Category = Technical Support

Actions

Update Technical Support tracker.
Archive transcript to Technical folder.

Another workflow:

Trigger

Ticket Closed

Condition

Category = Payment Support

Actions

Update restricted Payment tracker.
Archive transcript to restricted Payment folder.

This keeps sensitive workflows separated.

Avoid One Giant Workflow

It may be tempting to create one large automation handling:

General Support
Technical
Payment
Bug Reports
Streamers
Guilds
Applications

But each category may require different:

Fields
Permissions
Destinations
Staff
Retention policies

Separate workflows are often easier to understand and troubleshoot.

Google Sheets Trigger Example

A basic technical support workflow could use:

Trigger 1

Ticket Created

Action

Create Google Sheets row

Trigger 2

Ticket Escalated

Action

Update Escalated = Yes

Trigger 3

Ticket Resolved

Action

Update Resolution and Outcome

Trigger 4

Ticket Closed

Action

Update Status and Closed At

This creates a complete structured lifecycle.

Google Drive Trigger Example

For Drive, you usually do not need an archive on every ticket event.

A simpler workflow is:

Ticket Closed

↓

Archive Transcript

This avoids generating multiple files during the same conversation.

Why Not Archive on Every Update?

If you archive every time a ticket changes, you could end up with:

NOVUS-1042-v1
NOVUS-1042-v2
NOVUS-1042-v3
NOVUS-1042-v4
NOVUS-1042-final
NOVUS-1042-final2

Unless version history is intentionally required, one final archive is usually cleaner.

Google Sheets + Drive Combined Workflow

A complete setup may look like:

Ticket Created

Google Sheets:

Create record

Ticket Escalated

Google Sheets:

Update escalation

Ticket Resolved

Google Sheets:

Update resolution

Ticket Closed

Google Sheets:

Finalize ticket

Google Drive:

Archive transcript

This divides responsibilities appropriately.

Example Bug Report Workflow

Trigger: Form Submitted / Ticket Created

Create Bug Report row containing:

Report ID
Reporter
Title
Description
Steps
Component
Frequency

Trigger: Staff Takeover

Update:

Status = Under Review

Trigger: Resolved

Update:

Status = Resolved

Resolution = Fixed configuration issue

Trigger: Closed

Archive transcript to:

/Novus Archive/Bug Reports/

This gives developers both structured and detailed information.

Example Streamer Application Workflow

Ticket Created

Create Application record.

Staff Review

Update:

Status = Under Review

Decision

Update:

Status = Approved

or:

Status = Declined

Ticket Closed

Archive final ticket if required.

This creates a simple application-tracking process.

Example Guild Application Workflow

A similar workflow could be:

Guild Application Created

↓

Create Google Sheets record

↓

Staff Review

↓

Update status

↓

Application Decision

↓

Update outcome

↓

Ticket Closed

↓

Archive when required

Inactivity Closure

Some tickets may close because the member becomes inactive.

Do not report these as successfully resolved unless they actually were.

For example:

Status: Closed

Outcome: Inactive

This provides more accurate reporting.

Example Inactive Ticket

Ticket ID	Status	Outcome
NOVUS-1050	Closed	Inactive

Compare with:

Ticket ID	Status	Outcome
NOVUS-1051	Closed	Resolved

These tickets ended differently.

Manual Closure

Staff may also manually close a ticket.

Depending on your reporting needs, record:

Status: Closed

Outcome: Manually Closed

or use another consistent value.

Avoid automatically marking every closed ticket as resolved.

Failed or Unresolved Tickets

A concern may remain unresolved.

For reporting:

Status: Closed

Outcome: Unresolved

This helps identify:

Missing Knowledge
Product defects
Staff training needs
Common unsupported requests

Resolution Analytics

Once lifecycle triggers are recorded correctly, Google Sheets can help answer questions such as:

How many tickets were resolved?
How many required escalation?
Which categories generate the most tickets?
Which issues remain unresolved?
How many tickets were closed due to inactivity?

Accurate triggers make these reports possible.

Avoid Trigger Loops

Be careful when two systems can both update each other.

Conceptual example:

Novus updates Google Sheets

↓

Sheet automation sees change

↓

External workflow updates Novus

↓

Novus updates Google Sheets again

This can create an automation loop.

If two-way integration is available, define which system owns each field.

Define a Source of Truth

For each important value, decide which system is authoritative.

Example:

Ticket Status

Source of truth:

Novus

Google Sheets mirrors it.

Another example:

Developer Bug Priority

Source of truth:

Development Tracker

Novus may display it when supported.

Avoid allowing both systems to independently control the same value without clear rules.

One-Way Automation

A simple integration is usually one-way:

Novus

↓

Google Sheets

or:

Novus

↓

Google Drive

This is easier to maintain.

Two-Way Automation

A more advanced workflow may allow external changes to influence Novus when supported.

For example:

Google Sheets

Status changed to:

Approved

↓

Application workflow receives the updated decision.

Two-way workflows require stronger safeguards because synchronization conflicts can occur.

Do not design them unless your enabled integration explicitly supports them.

Retry Behavior

External services can temporarily fail.

Possible reasons include:

Google service interruption
Connection expiration
Permission changes
API rate limits
Network errors

If your integration provides retry handling, understand how retries affect Create actions.

Retry and Duplicate Risk

Imagine:

Create Sheet Row

succeeds.

The response fails before Novus confirms success.

A retry could potentially create a second row if the workflow has no duplicate protection.

A stable Ticket ID can help prevent this type of problem when supported by the integration.

Idempotent Workflow Concept

A well-designed automation should ideally be safe to retry.

For example:

Create or find Ticket ID NOVUS-1042

instead of blindly:

Create new row

every time.

This concept is often called idempotency.

You do not need to know the technical term to use the design principle:

Repeating the same automation should not create unintended duplicates.

Trigger Timing

Some actions should happen immediately.

Example:

Ticket Created

→ Create tracker row

Others should happen only after final processing.

Example:

Ticket Closed

→ Archive transcript

Choose the trigger based on when the necessary information becomes available.

Resolution Information Timing

Do not attempt to map:

Resolution

during:

Ticket Created

because no resolution exists yet.

Instead:

Ticket Created

→ Create empty record

Then:

Ticket Resolved

→ Add resolution

This reflects the actual ticket lifecycle.

AI Summary Timing

If an AI Summary is generated during final ticket processing, map it only after it exists.

Do not assume the summary is available at ticket creation.

The exact availability depends on the configured Novus workflow and plan features.

Transcript Timing

A transcript is usually most complete near ticket closing.

Archiving too early may produce a partial conversation.

A final archive trigger should be placed after the ticket contains the information your organization needs to retain.

Multiple Actions From One Trigger

A single trigger may conceptually perform several actions.

For example:

Ticket Closed

↓

Update Google Sheets.
Archive transcript to Google Drive.
Complete internal closing workflow.

However, each action should still be independently understandable and testable.

Workflow Dependencies

Sometimes one action depends on another.

For example:

Archive file to Google Drive

↓

Obtain archive reference

↓

Update Google Sheets archive field

If your enabled integration supports this pattern, Drive processing must succeed before the Sheet can receive a valid archive reference.

Do Not Pretend a Failed Step Succeeded

Suppose:

Google Sheets update: Success

Google Drive archive: Failed

The workflow should not treat both as successful.

Integration health should distinguish individual action failures whenever the enabled implementation provides that information.

Partial Success

A workflow can be partially successful.

Example:

Ticket closed successfully

Google Sheets updated successfully

Google Drive archive failed

This should be handled as:

Ticket operation succeeded, Drive integration requires attention

rather than reopening the entire support case automatically.

External Ticket Systems

When using:

Ticket Provider: EXTERNAL

the external ticket system owns important lifecycle events such as:

Channel creation
Native close process
Provider transcript generation

Novus should not assume it controls those events.

External Closing Consideration

If the external provider's transcript depends on its own Close button, bypassing that close process may prevent the normal transcript workflow.

For external ticket providers, staff-controlled closing is often safer when provider transcript preservation is important.

Native Ticketing

With:

Ticket Provider: NOVUS

Novus has clearer ownership of the native ticket lifecycle.

This makes native trigger behavior easier to coordinate with:

Transcript processing
Closing
Knowledge review
External integrations

Integration Trigger Testing

Test every important trigger independently.

Do not only test:

Ticket Created

and assume:

Resolved

and:

Closed

also work.

Each lifecycle stage can have different data available.

Recommended Test Scenario

Create:

NOVUS-TEST-001

Stage 1 — Created

Verify:

Google Sheets row appears.

Stage 2 — Escalated

Verify:

Same row updates.

Stage 3 — Resolved

Verify:

Resolution appears.

Stage 4 — Closed

Verify:

Closed date appears.

Stage 5 — Archive

Verify:

Google Drive file exists in the correct folder.

Test Failure Cases

Also test controlled failures.

For example:

Remove access to test Sheet
Remove access to test Drive folder
Rename test worksheet
Disable a test destination

Then verify that the integration failure can be identified.

Restore the correct configuration afterward.

Common Problem — Trigger Never Runs

Check:

Is the integration enabled?
Is the trigger configured?
Is the Ticket Category included?
Did the expected lifecycle event actually occur?
Is the correct destination selected?

Common Problem — Action Runs Too Early

Example:

Drive transcript is missing later conversation.

The archive trigger may be firing before final ticket processing.

Review trigger timing.

Common Problem — Duplicate Rows

If one ticket creates several rows, review whether several triggers are configured with:

Create

instead of:

Update

Common Problem — Duplicate Archives

If one ticket creates several transcript files, check whether multiple events are triggering the archive action.

A typical archive usually needs one final trigger.

Common Problem — Closed Ticket Still Shows Open

The Ticket Closed trigger may not be updating the existing record.

Check:

Unique key
Update action
Status mapping
Destination
Whether the close event ran

Common Problem — Resolution Missing

Check whether Resolution is mapped during the correct event.

Resolution may not exist during:

Ticket Created

Map it during a later lifecycle stage where it is available.

Recommended Basic Workflow

For most servers:

Ticket Created

→ Create Google Sheets record

Ticket Escalated

→ Update escalation status

Ticket Resolved

→ Update outcome and resolution

Ticket Closed

→ Finalize Sheet record

→ Archive transcript to Google Drive when required

This is a strong balance between automation and simplicity.

Recommended Minimal Workflow

If you only need historical records:

Ticket Closed

→ Create final Google Sheets row

→ Archive transcript

This is simpler but does not provide live tracking of currently open tickets.

Recommended Operations Workflow

For larger support teams:

Ticket Created

→ Create tracker record

Staff Takeover

→ Update handling mode

Escalation

→ Update escalation

Resolution

→ Update outcome and resolution

Ticket Closed

→ Finalize record

→ Archive

This provides more detailed operational visibility.

Automation Design Checklist

Before publishing an integration workflow, verify:

Every trigger has a clear purpose.
Every action has a clear destination.
Ticket Created uses Create only where appropriate.
Later lifecycle events use Update when appropriate.
A stable unique key is available.
Duplicate records are prevented.
Duplicate archives are prevented.
Category filters are correct.
Sensitive categories use restricted destinations.
Resolution is mapped only after it exists.
Transcript archiving happens at the correct stage.
Closed and Resolved are not incorrectly treated as identical.
Inactive and Unresolved outcomes are represented accurately.
Retry behavior does not create unintended duplicates.
Two-way automation does not create loops.
Source of truth is defined.
External ticket provider responsibilities are respected.
Native ticket lifecycle responsibilities are understood.
Partial integration failures can be identified.
Every major trigger has been tested.

Keep Automation Purposeful

More automation is not always better.

A workflow that runs on every possible event can become:

Difficult to troubleshoot
Expensive to maintain
Prone to duplicates
Difficult for staff to understand

Start with the lifecycle events that genuinely improve your support operation.

For most communities, that means:

Created

Escalated

Resolved

Closed

Then expand only when there is a clear reason.

Next Step

Continue to Managing Integration Connections & Permissions.