overview the tablechecks configuration object is a powerful tool that governs the behavior of various system operations by allowing the selective activation or deactivation of multiple predefined settings these settings encompass aspects such as permissions, validations, event triggers, and system protections, each of which influences how the system processes and interacts with data by configuring the tablechecks, users can tailor the execution environment to suit specific needs, enhancing script performance, ensuring data integrity, and maintaining security protocols this flexibility empowers administrators to manage system functionalities effortlessly, ensuring that only the necessary checks and processes are executed during any given operation there are a number of named tablechecks that encapsulate the different data access and security patterns examples of the different access patterns include an end user interacting with the system (listing, creating, updating records through the ui) tablechecks would have all the permission, restrictions, field value, workflow, trigger, and events enabled an integration creating/updating records tablechecks may have specific permission, restrictions, or workflow operations disabled, depending on the integration and its requirements an administrator performing bulk data import or data cleansing operations tablechecks may have all of the restrictions, workflows, validation etc disabled to allow the action a set of the named tablechecksare listed in a following section of this document warning avoid using current tablechecks( ) in server scripts that are part of the application lifecycle, such as triggers, workflows, or field value scripts doing so can overwrite the default set of checks applied to the record, meaning that from that point forward, critical restrictions, validations, field values, and system field updates may be bypassed this can lead to unintended behaviours downstream in the trigger/validation/workflow paths the current object is typically pre loaded with user perspective specific restrictions, ensuring security and data integrity disabling these checks indiscriminately can compromise these safeguards and affect the operation's consistency across the entire lifecycle use caution and ensure proper understanding of the script's context before altering table checks on shared objects like current for the case where you need to update a protected field on a shared object like current, use the withtablechecks method, as this scopes the different set of tablechecksto a specific block tablecheck options the auditenabled flag within tablechecks cannot be disabled in server scripts and remains permanently enabled, ensuring consistent auditing of operations across the system the following parameters can be adjusted within the tablechecks object record creation/update tablecheck name description example use cases enables or disables the evaluation of the ‘field default value’ functionality table and field properties data import, integration, bulk update administrators may choose to turn off the evaluation of ‘field default values’ when creating or updating information outside of the normal user flow enables or disables the evaluation of field values based on custom logic open screenshot 2024 11 18 at 4 19 28 pm png data import, integration, bulk update administrators may choose to turn off the evaluation of ‘field values’ when creating or updating information outside of the normal user flow enables or disables the evaluation of the ‘field validation (server)’ logic open screenshot 2024 11 18 at 4 21 10 pm png data import, integration, bulk update administrators may choose to turn off the evaluation of ‘field validation’ when creating or updating information outside of the normal user flow security tablecheck name description example use cases enables or disables the evaluation of the ‘table record restrictions’ functionality open screenshot 2024 11 18 at 4 24 36 pm png data import, integration, bulk update administrators may choose to turn off the evaluation of ‘table record restrictions’ when creating or updating information outside of the normal user flow protected data lookup (e g in triggers) administrators may choose to lookup information that the end user does not have permission to see e g looking up users, groups, cmdb items that the end user can not normally access enables or disables the evaluation of the multi tenancy restriction functionality data import, integration, bulk update administrators may choose to turn off the evaluation of ‘multi tenancy restriction’ when creating or updating information outside of the normal user flow protected data lookup (e g in triggers) administrators may choose to lookup information that the end user does not have permission to see e g looking up users, groups, cmdb items that the end user can not normally access enables or disables the evaluation of the permission model open screenshot 2024 11 18 at 4 26 33 pm png data import, integration, bulk update administrators may choose to turn off the evaluation of ‘multi tenancy restriction’ when creating or updating information outside of the normal user flow protected data lookup (e g in triggers) administrators may choose to lookup information that the end user does not have permission to see e g looking up users, groups, cmdb items that the end user can not normally access related record generation administrators may choose to create related records that the end user themselves are not permitted to create of view e g creating time card entries, even if the end user does not have permission to see or update time cards prevents any modifications to existing records to protect data integrity trigger, events and workflow tablecheck name description example use cases enables or disables the firing of the event processing logic data import, bulk update administrators may choose to turn off the 'fire events’ when creating or updating information outside of the normal user flow typically, this would only be advisable in the case where large amounts of data needed to be imported or updated and would typically be done intentionally as a performance optimisation enables or disables the evaluation of the ‘trigger’ functionality trigger data import, integration, bulk update administrators may choose to turn off the evaluation of ‘trigger’ when creating or updating information outside of the normal user flow enables or disables the execution of workflows data import, integration, bulk update administrators may choose to turn off the evaluation of ‘workflow operations’ when creating or updating information outside of the normal user flow system and managed field workflow related tablecheck name description example use cases enables or disables protection of ‘managed fields’ managed fields (e g workflowstatus, previoustransition, previousworkflowstatus, questionssource, systemrealm, systemrealmcidr) are explicitly marked as protected and are not permitted to be updated enables or disables protection of ‘managed fields’ managed fields (e g workflowstatus, previoustransition, previousworkflowstatus, questionssource, systemrealm, systemrealmcidr) are explicitly marked as protected and are not permitted to be updated data import, integration, bulk update data import, integration, bulk update ad ministrators may choose to turn off the protection of ‘managed fields’ when creating or updating information outside of the normal user flow enables or disables protection of ‘system fields’ system fields (e g id, updatedon, createdon, version, and tableclass) are explicitly marked as protected and are not permitted to be updated data import, integration, bulk update administrators may choose to turn off the evaluation of ‘system fields’ when creating or updating information outside of the normal user flow enables or disables the automatic update of 'system fields' (e g id, updatedon, createdon, version, and tableclass) data cleanup administrators may choose to turn off the automatic update of ‘system fields’ when correcting data issues, without forcing the update of the ‘updated on’ and ‘updated by' values predefined variables the tablecheckswrapper provides preconfigured sets of variables to assist in managing these checks defaultchecks (alias for validationtriggersvalueseventsnopermissionsnorestrictionsnotenancy) this is the default set of tablechecks that are applied to records when accessed from the scripting environment when using table api this api enables validations, event triggers, and field value evaluations, but disables permissions and all restrictions, both general and tenancy specific defaultprotectedchecks (alias for allchecksvalidationtriggersvaluesandevents) this is the default set of tablechecks that are applied to end user records, or from the scripting environment when using tableprotected api activates all system checks, including validations, event triggers, field value evaluations, and protection for managed and system fields enforces both general and tenant specific restrictions and permissions notablechecksnoevents disables permissions, validations, event triggers, and restrictions, while enabling audit and updates to system fields supports field default value evaluations for minimal interference withapplyrestrictions=false withapplytenancyrestrictions=false withauditenabled=true // true withcheckpermissions=false withevaluatefieldvalues=false withfielddefaultvaluesenabled=true // true withfireeventsenabled=false withpreventupdates=false withmanagedfieldsprotected=false withsystemfieldsprotected=false withtriggersenabled=false withupdatesystemfields=true // true withvalidationenabled=false withworkflowoperationsenabled=true // true notablecheckswithevents disables permissions, validations, triggers, and restrictions, but keeps event processing, auditing, and field value operations enabled withapplyrestrictions=false withapplytenancyrestrictions=false withauditenabled=true // true withcheckpermissions=false withevaluatefieldvalues=false withfielddefaultvaluesenabled=true // true withfireeventsenabled=true // true withpreventupdates=false withmanagedfieldsprotected=false withsystemfieldsprotected=false withtriggersenabled=false withupdatesystemfields=true // true withvalidationenabled=false withworkflowoperationsenabled=true // true notablecheckswitheventsandvalues deactivates permissions, validations, triggers, and restrictions, while retaining event processing, auditing, and default field value evaluations withapplyrestrictions=false withapplytenancyrestrictions=false withauditenabled=true // true withcheckpermissions=false withevaluatefieldvalues=true // true withfielddefaultvaluesenabled=true // true withfireeventsenabled=true // true withpreventupdates=false withmanagedfieldsprotected=false withsystemfieldsprotected=false withtriggersenabled=false withupdatesystemfields=true // true withvalidationenabled=false withworkflowoperationsenabled=true // true notablechecksnosystemfieldsnochecksnoevents disables all checks except auditing, including updates to system fields and event handling, focusing solely on maintaining audit logs withapplyrestrictions=false withapplytenancyrestrictions=false withauditenabled=true // only 'audit` is enabled withcheckpermissions=false withevaluatefieldvalues=false withfielddefaultvaluesenabled=false withfireeventsenabled=false withpreventupdates=false withmanagedfieldsprotected=false withsystemfieldsprotected=false withtriggersenabled=false withupdatesystemfields=false withvalidationenabled=false withworkflowoperationsenabled=false functions users can override attributes of these predefined table checks through the use of functions / determines whether restrictions should be applied to table records to ensure compliance with defined criteria / withapplyrestrictions(apply boolean) tablechecks; / enforces restrictions specific to tenant environments to maintain data segregation and security / withapplytenancyrestrictions(apply boolean) tablechecks; / controls the enforcement of permission checks, ensuring users have the necessary access rights / withcheckpermissions(apply boolean) tablechecks; / enables or disables the evaluation of field values based on custom logic / withevaluatefieldvalues(apply boolean) tablechecks; / allows the application of default values to fields during record creation for consistency / withfielddefaultvaluesenabled(apply boolean) tablechecks; / regulates the firing of events to facilitate communication and process handling / withfireeventsenabled(apply boolean) tablechecks; / prevents any modifications to existing records to protect data integrity / withpreventupdates(apply boolean) tablechecks; / protects managed fields like workflowstatus, previoustransition, previousworkflowstatus, questionssource, systemrealm, and systemrealmcidr / withmanagedfieldsprotected(apply boolean) tablechecks; / protects system critical fields including id, sid, updatedon, createdon, version, and tableclass from unauthorized changes / withsystemfieldsprotected(apply boolean) tablechecks; / indicates whether triggers should be active to automatically respond to events / withtriggersenabled(apply boolean) tablechecks; / manages updates to essential system fields such as id, sid, updatedon, createdon, version, and tableclass / withupdatesystemfields(apply boolean) tablechecks; / manages the validation processes to ensure data integrity and consistency / withvalidationenabled(apply boolean) tablechecks; / enables the execution of workflow operations to automate business processes efficiently / withworkflowoperationsenabled(apply boolean) tablechecks; usage examples 1\ applying tablechecks in a table query scenario you need to update a specific record in the "incident" table, disabling certain system field updates while performing the operation table("incident") equal("number", "inc0000249") tablechecks(tablechecks defaultchecks withupdatesystemfields(false)) foreach(rec => { rec shortdescription("update description") update(); }); explanation by setting up tablechecks during the initial query, all records returned are processed under the specified conditions in this example, system field updates are disabled, allowing the update to focus solely on the intended field changes without affecting system metadata 2\ modifying current with tablechecks scenario update a protected field in the current record where default restrictions are imposed, typically in scripts where current is shared across trigger, workflow, or field value scripts current withtablechecks(tablechecks notablechecksnosystemfieldsnochecksnoevents, () => { current protectedfield("new value"); }); explanation this setup allows temporary override of the default checks on the current object, which is preloaded with user imposed restrictions by employing notablechecksnosystemfieldsnochecksnoevents, the script can modify protected fields without the usual restrictions, ensuring that changes are localized to the block and do not disrupt other script functionalities considerations shared objects the withtablechecks method is optimal for shared/common objects like current to ensure that the operation respects the appropriate level of checks without affecting other scripts that may use the same object multiple record operations when performing operations on multiple records, initiate tablechecks at the start of the query process this prevents redundant checks and optimizes script performance by applying necessary conditions only once for all the records processed lifecycle and scope awareness it's important to understand the lifecycle and scope of tablechecks within your scripts proper application ensures that each operation is conducted with the required checks, preventing unintended side effects or security issues while maintaining the intended functionalities