CSA Questions Bank

A Many-to-Many (M2M) relationship in ServiceNow allows two or more tables to be related bi-directionally, so that related records are visible in a related list on both tables.

Unlike a One-to-Many (1:M) relationship (where only one table references another), M2M relationships link records in both directions.

This is achieved through an intermediary table, known as a Many-to-Many table, which stores the relationships.

A Many-to-Many table contains:

A reference field for each of the tables being linked.

The relationship records, which connect records between the two tables.

Suppose you want to relate Incidents to Problems and vice versa.

Instead of adding a reference field in each table, you create an m2m_incident_problem table.

Now, an Incident can be linked to multiple Problems, and each Problem can be linked to multiple Incidents.

These relationships will be visible as related lists in both tables.

How Many-to-Many Relationships Work in ServiceNow:Example of a Many-to-Many Relationship:

Incorrect Answer Choices Explanation:❌ A. Database View – Used to combine data from multiple tables for reporting but does not establish a bi-directional relationship between tables.

❌ C. One to Many (1:M) – A single record in one table relates to multiple records in another, but the relationship is not bi-directional.

❌ D. Extended – Refers to table inheritance, where a table inherits fields from its parent table, not a Many-to-Many relationship.

Many-to-Many Relationships in ServiceNow

Understanding Table Relationships

Official CSA Documentation Reference:

In ServiceNow Flow Designer, an Application-based trigger is used to initiate a flow based on events from a specific application. Before using an application-based trigger, you must ensure that the necessary application spoke and any required plug-ins are activated.

Application Spokes:

Spokes are pre-built integration modules that allow Flow Designer to interact with different applications within ServiceNow.

Each application that provides triggers typically has its own spoke.

Plug-ins:

Some application spokes rely on additional plug-ins for full functionality.

These plug-ins must be enabled before the application-based triggers can be used.

A. Activate application trigger spoke → Incorrect

There is no generic "Application Trigger Spoke." Instead, each application has its own spoke that must be enabled.

B. Activate trigger security rules → Incorrect

Security rules govern access to triggers, but they do not enable the functionality of application-based triggers.

D. Assign Application trigger role [sn_app_trigger_write] to SME → Incorrect

Roles like sn_app_trigger_write may provide permissions but do not activate the trigger itself.

E. Activate application plugins only → Incorrect

While plug-ins may be necessary, you also need to activate the corresponding spoke.

In ServiceNow, System Import Sets is the primary application used to import and transform data from external sources into the platform. It provides a structured way to load data into tables while allowing data transformation and mapping before final insertion.

Data Loading from External Sources:

Supports imports from CSV, Excel, XML, JSON, and JDBC databases.

Allows data from external systems to be brought into ServiceNow.

Staging Area for Data Processing:

Imported data first enters a temporary staging table (Import Set Table).

Data can then be transformed before being committed to the target table.

Data Mapping and Transformation:

Uses Transform Maps to map fields from the Import Set Table to the Target Table.

Supports automatic field mapping and scripted transformations.

Data Cleansing and Validation:

Duplicate records can be detected and removed.

Invalid or missing data can be corrected before insertion.

Navigate to System Import Sets (All → System Import Sets → Load Data).

Upload the data file (CSV, XML, JSON, etc.).

Create a Transform Map to define how data is mapped to the target table.

Run the transformation to move data from the Import Set Table to the final table.

Verify the data in the target table.

A company imports employee records from an external HR system (CSV file).

The System Import Sets module loads this data into a staging table.

A Transform Map moves the data into the User [sys_user] table.

Key Features of System Import Sets:Steps to Load Data Using Import Sets:Example Use Case:

Why Option C (System Import Sets) is Correct?✅ System Import Sets is the primary tool for loading data into ServiceNow from external sources.

Why Other Options Are Incorrect?❌ A. Service Level Management → Incorrect

Service Level Management (SLM) is used to track Service Level Agreements (SLAs), not to import data.

❌ B. Configuration → Incorrect

Configuration Management (CMDB) helps track configuration items (CIs) but does not handle data imports.

❌ D. System Update Sets → Incorrect

Update Sets are used to move configurations and customizations between instances, not to import data.

ServiceNow Docs – Importing Data with System Import Sets

ServiceNow Learning – Data Import & Transformation Best Practices

ServiceNow Developer Portal – Using Import Sets Efficiently

References from Certified System Administrator (CSA) Documentation:

In ServiceNow, Business Rules are server-side scripts that execute at specific times relative to database operations. The "When" setting determines when the Business Rule runs in relation to a record action (Insert, Update, Delete, Query).

Why is Option A Correct?✅ Before

Executes before a record is saved to the database.

Used to validate data, modify values, or prevent an action (e.g., stopping an invalid update).

✅ After

Executes after a record is inserted, updated, or deleted.

Commonly used for triggering notifications or creating related records.

✅ Async (Asynchronous)

Runs after a database operation but executes in the background.

Ideal for long-running or performance-heavy tasks (e.g., integrating with external systems).

✅ Display

Executes before a form loads, allowing modifications to fields before they are displayed to the user.

Typically used for pre-filling form fields based on user roles or conditions.

Why Are the Other Options Incorrect?❌ B. Prior to, Synchronous, on Update

"Prior to" is not a valid Business Rule execution timing.

"Synchronous" is a general term but is not a specific execution timing option in Business Rules.

"on Update" is a database operation, not an execution timing.

❌ C. Insert, Update, Delete, Query

These are database operations that trigger Business Rules, not execution timings.

Execution timing determines when (before, after, etc.), while these determine what triggers it.

❌ D. Before, Synchronous, Scheduled Job, View

"Synchronous" is not a Business Rule timing option.

"Scheduled Job" refers to Scheduled Jobs (not Business Rules).

"View" is a UI-related concept, not a Business Rule execution timing.

ServiceNow Business Rules - How They Work

ServiceNow Best Practices - Business Rule Execution Timing

ServiceNow Developer Documentation - Before, After, Async, and Display Business Rules

References to Official Certified System Administrator (CSA) Documentation: