Handling Skipped Records During HappySignals Application Updates

Guidelines for reviewing skipped records during HappySignals updates in ServiceNow. Covers how to handle system properties, ACLs, scripts, dictionary entries, and more to ensure update integrity and minimize post-update issues.

When updating HappySignals applications in your ServiceNow instance, some records may be skipped due to customizations, deletions, or conflicts with the base system. These skipped records appear in the Skipped Changes to Review list and must be reviewed carefully to ensure the updated application functions as expected.

Skipped records typically include:

• Modified records in the customer instance (e.g., scripts, ACLs, dictionary entries)
• Deleted records from the application developer (these are intentional and usually recommended to be applied)
• System properties or choice records that may be recreated or overridden

While some skips—such as changes in system properties—are expected and may not require action, others can directly impact the functionality of the new application version. For example, skipped scripts or ACLs may prevent new features from working correctly.

⚠️ Important: Even if a skipped record seems minor, it should never be ignored without review. Every skipped item should be resolved using one of the available resolution options to ensure clarity and maintain system integrity.

Resolution Options Explained

Each skipped record includes a Resolution field with three possible actions. Here's how to interpret and apply them:

Revert to Base System

• Use when: The customization is no longer needed or conflicts with the updated version.
• Effect: Discards your customization and restores the base system version. A customer update record is created.
• Recommended for:
  • Most dictionary entries
  • Unmodified ACLs
  • Priority 2 records that are listed in the update guide
  • Security records without valid custom logic
  • Deleted records that were removed intentionally by the application developer

✅ Preferred resolution in most cases, especially for major releases that introduce significant changes to integration logic or core mechanisms.

Keep (Retain)

• Use when: Your customization is intentional and still required.
• Effect: Keeps your existing record and ignores the upgrade change.
• Recommended for:
  • Scripts with validated custom logic
  • ACLs with deliberate access changes
  • System properties that are actively used

⚠️ Use with caution. Keeping a record may block new functionality. Prefer reverting or resolving conflicts unless you have a clear reason to retain the customization. Even if you choose to retain a record, you must still review it. Never leave skipped records unresolved without inspection.

Resolve Conflicts

• Use when: You want to merge the upgrade changes with your customization.
• Effect: Opens a form to merge individual fields manually.
• Recommended for:
  • Scripts where both old and new logic are needed
  • Dictionary entries with partial customizations
  • ACLs requiring fine-tuned access control

🛠️ Best practice for preserving look-and-feel customizations: Take note of UI or label changes and reapply them on top of the updated base version using this method.

📋 Record Type Guidelines

Best Practices

• Always update sub-production environments first.
• Use the Upgrade History to identify skipped records.
• Apply a resolution to every skipped record—do not leave any unresolved.
• Run test cases after resolving skipped records to validate functionality.
• Refer to the https://support.happysignals.com/release-notes for version-specific changes.
• Contact support@happysignals.com for help with complex conflicts.