Is there any way for a Record Producer item to not create a record?

[tahnalos]

We currently have a Record Producer that creates a process entry in a customized table.  This table was created with the intention that the process entry can be updated at any time.  Our service catalog currently sets this up via a record producer which is fine initially, but if the process entry needs to be modified, we want the ability to update it if needed.  While we can do the scriptwork to bring up the already created entry using Catalog Client scripts, we are wondering how do we not create a new record but to update one instead.  In other words, we want to make sure that the Producer part does not create an entry in this specific scenario.

Any ideas?

[tahnalos]

The Drop down variable won't work.  The business doesn't want it.

Because we are using 3 unique values, then we may have to use the record producer script to check if the record exists in the server or not.  Not sure if the current.setAbortAction (true) line would be suitable in this instance though as I am aware that it stops processing for every record in the "current" field scope.

I will check it out, but I would have preferred a much more flexible Record Producer design that allows us some flexibility to do what we really want to do.

[RaghavSh]

@tahnalos Let me summarise here:

1. Updates should be handled by catalog item and not record producers.

2. If you have such a complex scenario that it cant be handled by catalog item and you need record producers then use abort action to stop the insert in record producer scripts.

3. The flexible design you are aiming for which will allow insert/update as per need basis is not available as of now.

Please mark the answer correct/helpful accordingly.

[David Whaley]

You could set your record producer up to create a record in an import table and have your transform map create or modify the record in your customized table.

[John Gilmore]

Unfortunately a Record Producer is designed to create a record but you can simulate your situation. I am curious about the ServiceNow tech having issue with what you are doing and why they would pull support for the sc_req_items table? That seems like a very odd stance to take from ServiceNow when you should be allowed to modify those things in your instance as you please? Would creating a table that extends sc_req_items to fill this function be an acceptable option for ServiceNow?

But moving on to your specific use case.

The first problem is referencing the existing record in your record producer. Since Record producers are designed to create records they don't have an associated record to begin with. You will need a reference variable on the record producer mapped to a reference field on the table targeting the same table it creates records on. Depending on how users are getting to the record producer they could be required to select the record or it could be automatically set via script. Once it is set then you would likely need a client callable ajax script to get the existing record attributes (if the use case is to look up and see if there is a matching record then I'll cover that a bit further down).

For the second step you will require a boolean (True/False) variable on the record producer mapped to an identical field on the table. This field can be hidden in all views at it is strictly functional. Once the record attributes are loaded, and probably any time one of your 3 variable used for matching is changed, you would run a script to evaluate whether a new records is required or not. If a new record is required you could set this boolean field to False and if it is not then you could set it to True. If you perform the checks with scripts the user never needs to see the boolean field or know that this is happening.

The next step would be to create a flow that triggers when a record is inserted into the table and the boolean field has a value of True. This flow would then use the created record to update the referenced record accordingly and then delete the trigger record.

If the process needs to determine if there is an existing record in the table that matches the record producer being submitted and update it if so then the same basic strategy exists but it all happens in the onSubmit script instead. The onSubmit Script would call an ajax script which would look for a matching record, if found it would set the reference variable to the matching record and then set the boolean variable to True. The triggered flow would remain the same.

Functionally the Record Producer would provide the functionality the clients are looking for and by performing the update with a triggered flow that "cleans up after itself" to delete the new records after updating the existing one you would also avoid bloating the table with records that are solely for the purpose of updating other records.

[tahnalos]

ServiceNow seems to have an issue with the NUMBER of fields we have put on in the sc_req_item table.  Previous developers have been piling on customized fields on the sc_req_item table, we estimate around 200 fields that are only used once depending on the catalog item being used.  This is causing problems with ServiceNow updates and causing some stability issues on our end.   Which is why we are being pushed to use record producers so that these customized fields can start to be removed.  Creating an extended table is not ideal for our business as we have limited ability to create such extended tables due to corporate policy that restricts creation of new tables, extended or otherwise.  The table we are creating for process entries has been there for many years before the corporate policy took place.  So we are rather handcuffed in that manner, and are trying to set up the record producer to do what we want.