#6-Testing & Troubleshooting Integrations

An integration should always be tested before it handles real support data.

A configuration can appear correct while still sending:

• Data to the wrong spreadsheet
• Values into the wrong columns
• Transcripts into the wrong folder
• Duplicate records
• Sensitive information to an inappropriate destination

The safest approach is to test each part individually before testing the complete workflow.

The Integration Testing Process

A complete integration can involve several layers:

Connection

↓

Permissions

↓

Destination

↓

Mapping

↓

Trigger

↓

Action

↓

External Result

↓

Ticket Lifecycle

Testing should follow approximately the same order.

Do Not Test Everything at Once

Suppose you configure:

• Google Sheets
• Google Drive
• 15 field mappings
• 4 triggers
• 5 Ticket Categories

and then create one test ticket.

If something fails, there are many possible causes.

A better approach is:

Start small

↓

Confirm success

↓

Add another component

↓

Test again

This makes troubleshooting significantly easier.

Create Dedicated Test Resources

Before using production resources, create temporary destinations such as:

Google Sheets

Novus Integration Test

Google Drive

Novus Integration Test Archive

These allow you to test without mixing fake records with real support information.

Recommended Test Spreadsheet

Create:

Spreadsheet: Novus Integration Test

Worksheet: Tickets

Columns:

Ticket ID	Member	Category	Status	Resolution	Created At	Closed At

Start with these basic fields before testing complex Ticket Form mappings.

Recommended Test Drive Structure

Create:

Novus Integration Test Archive

with:

• General
• Technical
• Payment
• Applications

This allows category-to-folder mapping to be tested safely.

Step 1 — Test the Connection

First verify that the external service connection itself works.

For example:

Novus

→ Google Account

At this stage, do not worry about complex mappings.

Confirm that the intended account is connected.

Verify the Correct Account

If several Google accounts are signed in, confirm that you authorized the correct one.

For example:

Correct

Support Operations Account

Incorrect

Personal Google Account

This is a common source of configuration mistakes.

Step 2 — Test Resource Access

Next, verify that the connected account can access the intended resource.

For Google Sheets:

Can the account access:

Novus Integration Test

For Google Drive:

Can the account access:

Novus Integration Test Archive

If not, fix the external permission before troubleshooting Novus mappings.

Step 3 — Test Required Permissions

Being able to view a resource does not necessarily mean the integration can modify it.

For example:

Viewer

may be insufficient if the workflow needs to:

Create Row

or:

Update Row

Similarly, a Drive account needs sufficient permission for the archive operation required by the configured workflow.

Step 4 — Test a Simple Mapping

Start with one field.

For example:

Ticket ID

→

Google Sheets: Ticket ID

Create a test ticket.

Confirm the Ticket ID reaches the correct column.

Then add another field.

Step 5 — Add Core Fields

After Ticket ID works, add:

Ticket Owner

→ Member

Ticket Category

→ Category

Ticket Status

→ Status

Created At

→ Created At

Test again.

Step 6 — Add Ticket Form Fields

Once system fields work, test Ticket Form responses.

For example:

Form: Issue Type

→ Issue Type

Form: Problem Description

→ Description

Form: Error Message

→ Error

Use realistic form responses during testing.

Use Realistic Test Data

Instead of entering:

Issue: test

use:

Issue Type: Launcher

Problem Description: Launcher closes after selecting the server.

Error Message: No error message displayed.

Realistic data helps reveal:

• Formatting problems
• Long-text problems
• Incorrect mappings
• Empty-field behavior
• Choice-field behavior

Step 7 — Test Dropdown Fields

Suppose:

Issue Type

contains:

• Launcher
• Login
• Client
• Website

Select:

Launcher

Verify that the destination contains the expected value.

Step 8 — Test Multiple Choice Fields

Suppose:

Affected Platforms

allows:

• Windows
• Website
• Android

Select:

Windows + Website

Verify how the integration stores multiple values.

For example:

Windows, Website

The exact output depends on the enabled mapping implementation.

Step 9 — Test Optional Fields

Leave an optional field blank.

For example:

Error Code

Do not provide a value.

Verify that the integration handles the empty value without incorrectly failing the entire workflow.

Step 10 — Test Create Behavior

Create:

NOVUS-TEST-001

Verify that the integration creates one record.

Example:

Ticket ID	Status
NOVUS-TEST-001	Open

There should not be several identical rows from one creation event.

Step 11 — Test Update Behavior

Continue the same ticket.

Change its lifecycle state through the configured workflow.

For example:

Open

↓

Escalated

Verify that the existing record updates rather than creating an unintended duplicate.

Expected:

Ticket ID	Status
NOVUS-TEST-001	Escalated

Not:

Ticket ID	Status
NOVUS-TEST-001	Open
NOVUS-TEST-001	Escalated

unless you intentionally configured an event log.

Step 12 — Test Resolution

Resolve the test ticket.

Verify that the configured destination receives the expected resolution information.

For example:

Outcome: Resolved

Resolution: Launcher configuration corrected

Do not only verify that Status changed.

Check the actual resolution field as well.

Step 13 — Test Ticket Closing

Close the ticket through the intended workflow.

Verify:

• Status updates
• Closed At is populated when mapped
• Final outcome is correct
• Resolution remains available
• No duplicate record is created

Step 14 — Test Google Drive Archiving

If Google Drive is enabled for the workflow, verify that the expected archive appears.

For example:

Ticket

NOVUS-TEST-001

Category

Technical

Expected Destination

/Novus Integration Test Archive/Technical/

Verify the Archive File

Do not stop after confirming that a file exists.

Open it and verify:

• It belongs to the correct ticket.
• Expected ticket content is present.
• File naming is correct.
• It is stored in the correct folder.
• Access permissions are appropriate.

Step 15 — Test Category Routing

Create one test ticket for every important category.

For example:

General Support

Expected:

Sheet: General

Drive: General

Technical Support

Expected:

Sheet: Technical

Drive: Technical

Payment Support

Expected:

Sheet: Restricted Payment

Drive: Restricted Payment

Testing one category does not prove every category mapping is correct.

Step 16 — Test Sensitive Permissions

This is especially important for:

• Payment Support
• Account Support
• Private Applications
• Administrative Tickets

Create a test sensitive ticket.

Archive it.

Then attempt to access the destination using an account that should not have permission.

The account should not be able to access the restricted information.

Step 17 — Test Failure Scenarios

A strong integration test does not only test success.

It also verifies that failures can be identified.

Test controlled failures using temporary test resources.

Test Permission Failure

Using a test resource, remove the connected account's required edit access.

Run the workflow.

Verify that the operation does not silently appear successful.

Then restore the correct permission.

Test Missing Worksheet

Using a test spreadsheet, configure or simulate a destination worksheet that is unavailable.

Verify that the failure can be identified.

Restore the worksheet or correct the destination afterward.

Test Missing Drive Folder

Using the test environment, make the configured Drive destination unavailable.

Run the archive workflow.

Verify that the archive failure can be identified.

Do not perform destructive tests against production folders.

Test Revoked Authorization

If your environment allows safe reconnection testing, verify how the integration behaves when external authorization is unavailable.

Then reconnect the intended account and test again.

Understanding Integration Failures

Most integration problems belong to one of these categories:

Connection Problem

Novus cannot communicate with the external service.

Permission Problem

The connection exists, but the account cannot perform the required action.

Destination Problem

The configured spreadsheet, worksheet, or folder is unavailable.

Mapping Problem

The source or destination field is incorrect.

Trigger Problem

The expected automation event did not run.

Action Problem

The trigger ran, but the external operation failed.

Identifying the category first makes troubleshooting faster.

Troubleshooting Order

When an integration fails, check in this order:

1. Connection

↓

2. Account

↓

3. Permissions

↓

4. Destination

↓

5. Mapping

↓

6. Trigger

↓

7. Action

↓

8. External Result

Avoid randomly changing several settings at once.

Problem — Google Account Is Connected but Nothing Happens

A successful connection only confirms authorization.

It does not prove that:

• The workflow is enabled.
• The trigger ran.
• The account has destination access.
• The mapping is valid.
• The action succeeded.

Continue checking the rest of the workflow.

Problem — Google Sheet Is Not Updating

Check:

• Correct Google account
• Spreadsheet access
• Correct spreadsheet
• Correct worksheet
• Mapping
• Unique key
• Trigger
• Update action
• Ticket lifecycle event

Problem — New Rows Work but Updates Do Not

If Ticket Created successfully creates a row but later changes do not update it, investigate:

Unique Key

and:

Update Configuration

The integration may not be able to identify the existing row.

Example

Created:

Ticket ID	Status
NOVUS-1001	Open

Later:

Ticket ID = NOVUS-1001

should allow the workflow to locate that record.

If the unique identifier is missing or incorrect, update behavior may fail.

Problem — Duplicate Rows

Example:

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

Possible causes:

• Multiple Create actions
• Incorrect trigger design
• Missing unique key
• Retry behavior
• Duplicate integrations
• Intended update configured as create

Fixing Duplicate Rows

Determine first whether the Sheet is intended to be:

Ticket Tracker

or:

Event Log

For a Ticket Tracker, use:

Ticket Created → Create

and later events:

→ Update

when supported.

Problem — Wrong Data in Column

Example:

Ticket Category

appears under:

Member

This is a mapping problem.

Review:

Source

→

Destination

Do not rely only on spreadsheet column order.

Problem — Form Field Is Blank

Check:

• Was the field optional?
• Did the member provide a value?
• Is the correct Ticket Form active?
• Is the mapping using the correct field?
• Was the field renamed?
• Was the field deleted?

A blank value is not always an error.

Problem — Mapping Broke After Editing a Form

Ticket Form changes can affect integration mappings.

For example:

Old:

Issue

New:

Issue Type

If the integration still references the old source, review the mapping.

Always test integrations after changing Ticket Forms.

Problem — Mapping Broke After Editing Google Sheets

External changes can also break workflows.

Check whether someone:

• Renamed the worksheet
• Removed a column
• Changed the destination
• Removed account access
• Deleted the spreadsheet

Review the integration after structural changes.

Problem — Google Drive File Is Missing

Check:

• Google connection
• Account permission
• Folder destination
• Category mapping
• Archive trigger
• Ticket closing workflow
• Whether archive generation actually occurred

Do not assume the issue is automatically Google Drive itself.

Problem — Archive Goes to Wrong Folder

Example:

Payment Support

archive appears under:

General

Check:

Ticket Category

↓

Category Mapping

↓

Drive Destination

This is especially important because wrong-folder routing can create a privacy issue.

Problem — Duplicate Transcript Files

Possible causes:

• Archive action runs on multiple triggers.
• Closing process executes more than once.
• Retry creates another archive.
• External ticket provider also creates an archive.
• Another automation archives the same ticket.

Determine which system should own the official archive.

Problem — Sheet Succeeds but Drive Fails

This is a partial integration failure.

For example:

Ticket Closed: Success

Google Sheets: Success

Google Drive: Failed

Do not assume the entire ticket operation failed.

Troubleshoot the Drive action independently.

Problem — Drive Succeeds but Sheet Fails

The reverse can also happen.

For example:

Transcript Archive: Success

Google Sheets Update: Failed

Check the Sheets:

• Permission
• Worksheet
• Mapping
• Unique key
• Update action

Do not recreate the Drive archive unnecessarily.

Problem — Connection Suddenly Stops Working

If a previously working integration fails without a Novus configuration change, check for external changes.

Possible causes include:

• Authorization revoked
• Google account disabled
• Password/security changes
• Organization policy changes
• Resource permission removed
• Resource ownership changed

External services can change independently of Novus.

Problem — External Ticket Does Not Have Expected Fields

When using:

Ticket Provider: EXTERNAL

do not assume every native Novus field is available.

For example, an external ticket may not have:

• Native Novus Ticket ID
• Novus Ticket Form responses
• Provider-specific metadata

Use only information reliably available to that workflow.

Problem — External Transcript Is Missing

If your external ticket provider normally creates transcripts during its own Close process, make sure Novus is not bypassing the provider's required closing workflow.

When transcript preservation is important, staff-controlled external closing is generally safer.

Problem — Status Says Closed but Outcome Is Wrong

Do not automatically map:

Closed

to:

Resolved

A ticket may close because it was:

• Resolved
• Inactive
• Unresolved
• Manually closed

Use separate Status and Outcome fields when your reporting requires this distinction.

Problem — AI Summary Is Empty

If your workflow maps an AI Summary, verify that the summary exists at the lifecycle stage where the integration runs.

Do not expect final summary information during Ticket Created.

AI Summary availability may also depend on the enabled Novus configuration.

Problem — Resolution Is Empty

Resolution information may not exist until the concern has actually been resolved.

Check whether the mapping runs during:

Ticket Resolved

or another appropriate final-processing stage.

Troubleshooting Google Sheets

When Sheets fails, check:

Connection

Is Google authorized?

Account

Is it the correct account?

Spreadsheet

Does it exist?

Permission

Can the account edit it?

Worksheet

Does it exist?

Mapping

Are source and destination correct?

Unique Key

Can the existing record be identified?

Trigger

Did the workflow run?

Troubleshooting Google Drive

When Drive fails, check:

Connection

Is Google authorized?

Account

Is it correct?

Folder

Does it exist?

Permission

Can the account use the destination?

Category Mapping

Is the correct folder selected?

Trigger

Did archive processing run?

File

Was the expected archive actually generated?

Troubleshooting Duplicate Data

When duplicates appear, check:

• Multiple active integrations
• Multiple Create actions
• Trigger overlap
• Retry behavior
• Missing unique key
• External automation
• Third-party ticket provider behavior

Do not delete records before identifying why duplicates are being created.

Troubleshooting Permissions

If data reaches the correct destination but the wrong staff can access it, the integration technically transferred the data—but the configuration still has a security problem.

Review:

• Parent folder access
• Spreadsheet sharing
• Shared links
• Organization-wide permissions
• Former staff access
• Sensitive category separation

Test After Every Major Change

Re-test the integration after changing:

• Google account
• Authorization
• Spreadsheet
• Worksheet
• Drive folder
• Ticket Category
• Ticket Form
• Field mapping
• Trigger
• Unique key
• Permissions
• Closing behavior

A previously working integration may no longer match the new configuration.

Use a Known Test Ticket

Keep a standard test scenario.

For example:

Ticket: NOVUS-TEST-001

Category: Technical Support

Issue Type: Launcher

Problem: Launcher closes after server selection

Expected Status Flow:

Open → Escalated → Resolved → Closed

Expected Sheet: Technical

Expected Drive Folder: Technical

Using the same scenario makes future configuration changes easier to verify.

Full End-to-End Test

A complete production test should simulate a real member.

1. Create Ticket

Verify:

• Correct Ticket Category
• Correct Ticket Form
• Correct Ticket ID

2. Submit Form

Verify:

• Form values are captured
• Required fields behave correctly

3. Google Sheets

Verify:

• One row is created
• Correct columns are populated

4. AI Assistance

Use the ticket normally.

5. Escalate

Verify:

• Existing Sheet record updates
• No duplicate row appears

6. Staff Takeover

Verify applicable operational fields.

7. Resolve

Verify:

• Outcome
• Resolution
• Status

8. Close

Verify:

• Closed At
• Final Status
• Transcript processing

9. Google Drive

Verify:

• Correct file
• Correct folder
• Correct filename
• Correct permissions

10. Final Review

Verify the same Ticket ID can be followed across the complete workflow.

Sensitive Workflow Test

Run a separate test for a sensitive category.

For example:

Payment Support Test

Verify:

Discord

Only authorized roles can access the ticket.

Google Sheets

Only authorized staff can access the record.

Google Drive

Only authorized staff can access the archive.

A successful data transfer with incorrect privacy settings is still a failed production test.

External Ticket Workflow Test

When using an external ticket provider:

1. Create ticket using the external provider.

2. Verify Novus can assist inside it.

3. Test the intended integration mapping.

4. Resolve the concern.

5. Close using the intended provider workflow.

6. Verify the provider transcript if required.

7. Verify Novus does not unintentionally create duplicate archives.

This confirms both systems work together.

Native Ticket Workflow Test

When using Novus In-House Ticketing:

1. Create ticket from the Novus panel.

2. Submit the configured Ticket Form.

3. Verify native ticket creation.

4. Verify Google Sheets mapping when enabled.

5. Test AI support.

6. Test staff escalation/takeover.

7. Resolve the concern.

8. Complete closing.

9. Verify transcript processing.

10. Verify Google Drive archive when enabled.

11. Verify final Google Sheets data.

This tests the complete native lifecycle.

Do Not Test With Real Sensitive Information

When testing Payment, Account, or other restricted workflows, use fictional data.

For example:

Reference: TEST-12345

Do not use:

• Real passwords
• Real payment credentials
• Real OTP codes
• Real authentication tokens

Test functionality without exposing real sensitive information.

Moving From Test to Production

After the integration passes testing:

1. Select the production destination.

2. Verify production permissions.

3. Review all mappings.

4. Review triggers.

5. Verify unique keys.

6. Remove temporary test routing.

7. Run one final controlled production test.

Do not simply change the destination and assume everything remains correct.

Keep Test Resources

You may keep a dedicated:

Novus Integration Test

spreadsheet and:

Novus Integration Test Archive

folder for future configuration testing.

This is safer than experimenting directly on production resources.

Production Troubleshooting Rule

When a production integration fails:

Do not change everything at once.

Change one variable.

Test.

Observe the result.

Then continue.

Otherwise, you may fix the problem without knowing what actually caused it.

Integration Troubleshooting Checklist

When something fails, verify:

• Correct external account is connected.
• Authorization is active.
• Connected account has required permissions.
• Spreadsheet exists.
• Worksheet exists.
• Drive folder exists.
• Correct destination is configured.
• Ticket Category mapping is correct.
• Source fields exist.
• Destination fields exist.
• Ticket Form has not changed unexpectedly.
• Unique key is valid.
• Create/update behavior is correct.
• Trigger is enabled.
• Expected lifecycle event occurred.
• Duplicate automation is not active.
• Retry behavior is not creating duplicates.
• External provider is not performing the same archive operation.
• Sensitive destination permissions are correct.
• Status and Outcome are mapped correctly.
• Resolution is available at the expected stage.
• Final archive contains the expected ticket.
• The same Ticket ID can be traced across systems.

Pre-Production Checklist

Before using an integration with real members:

• Test connection.
• Test permissions.
• Test Google Sheets.
• Test Google Drive.
• Test system fields.
• Test Ticket Form fields.
• Test optional fields.
• Test choice fields.
• Test create behavior.
• Test update behavior.
• Test duplicate prevention.
• Test escalation.
• Test resolution.
• Test closing.
• Test archive generation.
• Test category mapping.
• Test sensitive categories separately.
• Test unauthorized access.
• Test controlled failures.
• Test reconnection where appropriate.
• Test external provider behavior if used.
• Test native ticket behavior if used.
• Verify production destinations.
• Complete one full end-to-end test.

Recommended Testing Principle

A production integration should answer five questions successfully:

Did the correct trigger run?

Did the correct data get selected?

Did it reach the correct destination?

Could only the correct people access it?

Can the workflow recover or clearly expose a failure?

If all five are verified, the integration is much safer to use with real support workflows.

Next Step

Continue to Integration Best Practices & Recommended Setups.