A guide to understanding field-level data mapping in your ServiceNow integration to unlock the full value of HappySignals.
Why does data mapping matter?
When integrating HappySignals with ServiceNow, ticket data — like category, Region, or assignment group — is sent along with survey responses. This data allows you to:
-
Segment feedback results (e.g., by location, team, service area)
-
Track trends over time
-
Benchmark against other HappySignals customers
Correctly mapped data helps you get accurate, practical, and actionable insights from day one. Incomplete or inconsistent data limits what you can learn from the results — or even breaks benchmark compatibility.
FAQ
What's data mapping in this context?
Data mapping means selecting which fields (like Region or Service) from your ServiceNow tickets are included with the survey data sent to HappySignals.
Each field is passed as a key-value pair in the integration. For example:
"region": "EMEA"
"assignment_group": "Service Desk Tier 1"
This lets you later view and filter feedback by these values in your HappySignals portal.
What are the minimum required fields?
HappySignals needs a small set of mandatory fields to make the integration work. These are essential for triggering surveys and linking responses to tickets.
Field | Why it's needed |
---|---|
Ticket Number (var1 ) |
Links survey response to the correct ticket |
Enterprise Management Area (esm ) |
High-level classification (e.g., IT, HR) |
Ticket Type (t ) |
Differentiates Incidents and Requests |
Category (var2 ) |
Determines which survey form is shown |
Resolution or Closure Timestamp (d ) |
Defines when the survey is sent |
Note: These fields must be populated correctly for surveys to work as expected.
Recommended Fields for Added Value
We recommend including the following optional fields in your data mapping to unlock the full value of the HappySignals platform. These fields support segmentation, trend analysis, and more accurate, actionable reporting.
Even if these fields are not currently populated in your ITSM system, we recommend mapping them in advance and hiding the card in HappySignals until data is available — this avoids rework later.
Field | Why it's valuable | Ticket Type |
---|---|---|
Assignment Group(s) | Identifies the team responsible for the ticket. Enables performance and experience comparison across support groups. | Both |
Business Service / Service Offering | Ties feedback to specific services (e.g., Email, VPN, Device Support). Helps correlate experience with service performance. | Both |
Business Unit / Company | Distinguishes between sub-entities or organizations in multi-tenant environments. Useful for internal reporting and ownership. | Both |
Catalogue Item | Represents the specific item requested by the end user, typically from a service catalog. | REQ |
Category | Logical grouping of the issue (e.g., “Laptop”). Supports segmentation and filtering. Often a driver of which survey is sent. | INC |
Channel |
How the ticket was created (e.g., Portal, Phone, Email, Chat, Walk-In, Virtual Agent). Benchmarkable values — must follow standard format. Helps compare experience across contact methods. Example: A customer finds that satisfaction is lower via Phone and higher via Chat. They decide to promote Chat more visibly in the portal. |
Both |
Configuration Item | Specifies the system or asset affected (e.g., a specific laptop model or VPN gateway). Enables root cause insights. | INC |
Country | Enables comparison with HappySignals' global benchmarks. Should follow ISO naming conventions. | Both |
Department | Helps segment experience data by business function (e.g., Sales, Finance, HR). Useful for organizational feedback views. | Both |
Employee Start Date | Indicates employee tenure. Allows you to explore how new employees experience support. | Both |
Impacted Service | The named service affected by the ticket (e.g., Email, ERP System). Useful for service-level insights and trend analysis. | INC |
Location | Describes the employee’s office or work location — e.g., "London HQ" or "Remote." Avoid street-level details to protect privacy. Useful for hybrid work analysis. | Both |
Priority | Indicates ticket urgency and can highlight differences in satisfaction between low- and high-priority cases. | Both |
Reassignment Count | Tracks how many times the ticket was handed over. High values may suggest unclear ownership or inefficient processes. | INC |
Region | Enables regional segmentation (e.g., EMEA, North America). Reveals geographic trends and variation in experience. | Both |
Reopen Count | Shows whether tickets are being reopened after resolution. Can point to recurring issues or premature closure. Often unavailable for Requests. | INC |
Resolution Code | Identifies how the issue was resolved (e.g., workaround, permanent fix). Supports problem analysis and reporting. | INC |
Role | Employee’s job function (e.g., Developer, Sales Manager). Useful for analyzing support experience by user persona. | Both |
Service Request Status | The final lifecycle state of the request — e.g., “Closed Complete” or “Closed Incomplete.” | REQ |
Sub-Category | Further classification under Category (e.g., “Keyboard” under “Laptop”). Useful for detailed insights. | INC |
Vendor(s) | Identifies external service providers or suppliers involved. Allows internal vs. external performance comparisons. Include all vendors if the ticket contains tasks. | Both |
Why is benchmark data different?
Some data fields — especially Country and Channel — are used for global benchmark comparison. These fields must follow strict formatting rules.
For example:
-
Channel values must be exactly one of:
Portal
,Phone
,Email
,Chat
,Walk In
,Virtual Agent
-
Country must be a standard ISO country name (e.g.,
Finland
,Germany
,United States
)
If these values deviate, benchmark comparison will not be possible.
What to avoid when mapping fields
While it's important to include as much useful context as possible, there are also some types of data that should not be included in your HappySignals integration:
🚫 Personally Identifiable Information (PII): Do not send any fields that directly identify individual users. For example:
-
First or last names
-
Email addresses (except for survey delivery)
-
Phone numbers
-
Manager names or reporting lines
-
IP addresses
PII is not used in any part of HappySignals reporting or benchmarking, and including it can violate data privacy policies.
🚫 Too granular or overly specific values: Avoid mapping fields that contain overly detailed or one-off values that won’t scale well in segmentation. For example:
-
Full error messages
-
Custom free-text fields
-
Device serial numbers
These types of values can clutter reporting and make trend analysis harder. Instead, use normalized categories (e.g., "Laptop," "VPN," "Printer," etc.) that allow for consistent grouping.
⚠️ Inconsistent naming conventions: If the same concept (e.g., a business unit or service category) is labeled differently across services or ticket types, reporting will be fragmented. Try to maintain a consistent naming structure and avoid typos, case mismatches, or non-standard abbreviations.
Do all services need to use the exact data mapping?
Yes — or at least they should.
For best results, we recommend using a consistent data mapping across:
-
Incident and Request tickets
-
All measured services
-
All measurement channels (e.g., Proactive, Portal)
This ensures you can compare and segment results reliably across the IT support organization.
Best Practices
-
Document your mapping choices from the start. This makes it easier to maintain and adapt over time.
-
Keep data consistent across services and channels. If Region is included in one place but not another, your segmentation will be incomplete.
-
Add fields even if values are currently empty. You can hide them in HappySignals if needed — they'll be ready when the data becomes available.
-
Use benchmark-compliant values for Country and Channel fields.
Still unsure?
Your HappySignals customer success manager or solution consultant can help you review your mapping plan and ensure your data supports your goals — now and in the future.