Discovery Identity Sensor error: GlideRlideRecord.setTableName - empty table name (sys_script_include.d408790d0a0a0b020064fd47ecf276c4.script; line 43)Issue Discovery Identity Sensor error: Script error in sensor: org.mozilla.javascript.EvaluatorException: GlideRecord.setTableName - empty table name (sys_script_include.d408790d0a0a0b020064fd47ecf276c4.script; line 43) This exception is thrown by the RecordToHTML script include during sensor processing in the instance for Discovery Identify sensors, such as "CIM - Classify".CauseThe cause is that the sensor code believes it has inserted the new CI, but then can't see it again. This can be caused by at least the following: Something prevented the insert: A Data Policy that prevents the insert of the CI. It could be that custom fields have been set as mandatory, which discovery would have no way of filling in, preventing the record insert.An Abort Insert business rule, might in theory cause this. The insert happened, but something then prevents the sensor code seeing it afterwards: A custom Query Business Rule, that hides the record after it has been inserted.Domain Separation, Company Separation, ACL rules, and a low-level database query error would also cause this ResolutionIn the Discovery Status record that includes the error, find the Discovery Device History record for the IP address giving the error. This will give the class of the CI. Investigate all possible causes of a CI not being able to be inserted in that class/table, or that might hide the record from the sensor code running as system immediately after if was inserted. Where a customisation such as a Mandatory field Data Policy, or Query Business Rule is found to be the cause, redesign that implementation so it does not cause problems for Discovery. Note: Business rules and Data Policies can be inherited from parent classes in the CMDB tree/hierarchy, so be sure to check all relevant classes and not just the class of the CI. For Query Business rules, consider: The business rule may be dependent on field values that are not yet populated when the discovery sensor initially inserts it.The business rule may have been written based on the (wrong) assumption that it is only actual users that would be affected by it. If may be querying for attributes of the user in the condition for hiding the records. In that case a condition including gs.getSession().isInteractive() will be needed to prevent it affecting background jobs running as system. For Data Policy: Think about using another method to make the field mandatory on forms, such as setting this in the Dictionary, or by using UI Policies.Setting Mandatory field Data Policy on specific CI sub-classes only, and not the whole CMDB, is generally not a good idea due to the chance of Data Loss when re-classifying record. For ACLs: Be sure any custom ACLs have the mid_server role added to them, so all discovery sensors running as the MID Server still can see the records. For Domain Separation, Company Separation: The CIs, Relationships, and MID Servers should all be in the same Domain.