Certified Application Developer CAD Dumps PDF

Application Access is a feature that allows you to control the access level of other application scopes to your application’s data tables. You can use Application Access to control the following database operations:

Create: This operation allows the user to create new records on the table. You can enable or disable this operation by selecting or clearing the Can create option.

Delete: This operation allows the user to delete existing records on the table. You can enable or disable this operation by selecting or clearing the Can delete option.

Read: This operation allows the user to view the records on the table. You can enable or disable this operation by selecting or clearing the Can read option.

Write: This operation allows the user to modify the records on the table. You can enable or disable this operation by selecting or clearing the Can write option.

The one database operation that cannot be controlled with Application Access is Query. Query is not an operation, but a method of the GlideRecord class that is used to retrieve records from the database on the server-side. Query is not part of the Application Access rules, but it is affected by the Access Controls and the user’s roles.

References:

Application Access

[GlideRecord methods]

The syntax used in a Record Producer script to access values from Record Producer form fields is producer.variable_name. A Record Producer is a type of catalog item that allows users to create records on any table from the service catalog. A Record Producer script is a server-side script that runs when a Record Producer is submitted, and can be used to set values or perform actions on the generated record. The producer object is a global object that represents the Record Producer form and its variables. The variable_name is the name of the variable defined in the Record Producer. References: [ServiceNow Docs - Record producers], [ServiceNow Docs - Record producer script]

Global applications can use Automated Test Framework and Flow Designer features, but not Source Control and Delegated Development features. Source Control and Delegated Development features are only available to scoped applications . References: [Global vs Scoped Applications], [Delegated Development]

In ServiceNow, Access Controls (ACLs) determine the permissions required for users to access or modify data. For a user to pass an Access Control, the following conditions must be met:

Conditions configured in the Access Control must evaluate to true: Access Controls can have specific conditions set in the "Condition" field. These conditions are evaluated against the current record, and must return true for the Access Control to grant access.

The user has one of the roles specified in the Required roles related list: Access Controls can specify certain roles that a user must possess to gain access. If the user holds at least one of these roles, this criterion is satisfied.

Scripts configured in the Access Control must evaluate to true: Access Controls can include scripts that perform more granular checks. The script must execute without errors and return true for the user to pass the Access Control.

Option A is incorrect because Business Rules do not grant access; they are server-side scripts that execute based on record operations but do not control security permissions.

Option D is misleading. Each Access Control is evaluated independently. While multiple Access Controls can apply to a single operation, passing one does not inherently grant access unless it is the most specific match.

For more detailed information, refer to the official ServiceNow documentation on Access Controls:

servicenow.com