Incident Record Producer bypass ACL for user

[Lance Crowder]

I have an ask to explain why a user who does not have ACL access to create or write to the Incident table can use a Record Producer (RP) to create an Incident and how the record can be created without all of the mandatory fields included.  They want me to show documentation to support my findings.  So far, I understand that the RP Record has its own independent ACLs that allow the user access, and that the RP can bypass ACLs, Business Rules, and field validations, but I do not understand how and cannot seem to find any documentation to point me in the right direction. 

[JenniferRah]

You are correct: a user with no roles can create an Incident via a record producer or a Request/RITM via a catalog item. Depending on how your instance is set up, you can require that the user is logged in, but they don't have to have a role to do that. 

As to why something can be created without all the required fields: the fields are required on the client side (front end). The record producer creates the record on the server side (back end), which bypasses the required fields. The best case would be for your record producer to account for this and fill out all required fields. If not, the first person to modify the record after it's submitted will have to fill those out.

[Benjamin A]

Adding onto this.

If you are familiar with creating a record via the GlideRecord API, think of a record producer as a "system user" inserting a GlideRecord. There are no required fields.

If you want to require fields, modify the variables associated with the RP to be mandatory. Additionally, if you want to always pre-populate fields this can be done either with a template (simplest) or with the script field on the RP. For example if you wanted all incidents submitted by the RP to have a specific assignment group simply create an incident template and assign that to the RP or add current.assignment_group = "{sys_id}"; to the script field. More information on this can be found here.

As far as business rules go, they should still evaluate when using a RP. To see an example of this, in a sub-prod instance create a blank RP for the incident table and a BR with no conditions and have it take some action. You should notice when you submit the RP the BR still runs.

[Sandeep Rajput]

@Lance Crowder According to this documentation "

A record producer is a specific type of catalog item that allows end users to create task-based records, such as incident records, from the service catalog.

"

The sole purpose of a record producer is to help end users by creating incident(or any task based record for that matter) via self-service or a virtual agent. Catalog items/Record producer help in reducing load from the Service Desk and promote self service.

As rightly mentioned by you, RP records have their own ACLs and access for the end-users can be governed via User Criteria. If your organisation doesn't want to allow end-users to use the record producers then you may choose to deactivate them.

Regarding mandatory fields, they are usually enforced via UI Policies and Client script and defined at the table level. The UI Policies or client script defined for incident table will not work for Record producer meant for generating incidents. You need to have separate catalog client script or UI Policies defined at the record producer level to support the validations. You can also choose to create Data policy at the incident table level if you do not wish to create separate UI Policies/scripts for this purpose.