Add Custom Attribute Mapping in Jamf SG Connector

[Mahesh Kumar3]

We are using the OOB Jamf SG connector to synchronize computer records from Jamf into ServiceNow.

We have a requirement to ingest additional attributes that are not mapped by default. For example:

• general.remote_management.managed
• security.firewall_enabled

These attributes are present in the Jamf payload and need to be mapped to fields on the Computer [cmdb_ci_computer] table.

At the Transformer Definition level:

• temp.general.remote_management and temp.security entities already exist.
• I can also see impToTemp.general.remote_management and impToTemp.security entity mappings.

However, it is unclear how to properly configure the Entity Field Mappings so that Jamf updates the corresponding fields on the Computer table using these attributes.

Questions:

1. What specific changes are required in the Transformer Definition to support mapping these additional attributes?
2. Do we need to create new Entity Field Mappings under the existing entities, or modify the impToTemp mappings?
3. Are any changes required in the Identification & Reconciliation rules to ensure updates occur correctly?

Any guidance on the correct approach to extend the OOB Jamf transformer for additional attributes would be appreciated.

[YashwanthV18760]

Hi @Mahesh Kumar3 ,

This behavior is expected and is related to how the Jamf Service Graph Connector processes data. The connector uses Robust Transform Engine (RTE) to transform staging data into CMDB CI classes and then inserts it through Identification and Reconciliation Engine (IRE), so attributes will not populate CMDB fields unless explicit field mappings exist in the transformer.
https://www.servicenow.com/docs/r/servicenow-platform/service-graph-connectors/sgcc-configure-jamf-i...

Seeing entities like temp.general.remote_management or impToTemp.security confirms that data is already being received from Jamf correctly, but they will not update cmdb_ci_computer unless Entity Field Mappings are configured for those attributes.
https://www.servicenow.com/docs/r/servicenow-platform/service-graph-connectors/cmdb-jamf-classes.htm...

The correct solution is to extend the existing transformer configuration rather than modifying ingestion logic or OOB mappings.

Steps to resolve:

1. Navigate to IntegrationHub ETL → Transformers.

2. Locate the transformer tied to the SG-Jamf Computers data source.

3. Open the entity matching your payload path (for example security or general.remote_management).

4. Create a new Entity Field Mapping.

5. Map source attribute → target field on cmdb_ci_computer.

6. Save and publish the transformer.

7. Run a test import.
   https://www.servicenow.com/community/itom-forum/add-custom-attribute-mapping-in-jamf-sg-connector/td...

You should NOT modify impToTemp mappings because those belong to the ingestion layer and are part of the connector’s internal pipeline. Only extend mappings in the transformer layer.

No Identification & Reconciliation rule changes are required unless the new attribute is intended to act as an identifier. IRE only evaluates identifier fields such as serial number, name, or MAC address, so additional attributes do not affect reconciliation.

Best practice is to extend the data model safely by adding custom fields to the CMDB class and mapping them through new Entity Field Mappings rather than altering OOB tables or scripts. This ensures upgrade safety and connector stability.

To validate incoming values, review records in the staging table for SG-Jamf Computers. If the attribute exists there, it can always be mapped through transformer configuration.
https://www.servicenow.com/docs/r/servicenow-platform/service-graph-connectors/sgc-jamf-conn.html

Summary:
Data ingestion is already working correctly. The only missing step is creating new Entity Field Mappings in the existing transformer entity. No connector modification, no cross-scope change, and no IRE update are required.