We are adding a custom field (of type List/Record -> Department) to all our transaction records as well as some custom records. I know transactions already have a native department field, we are using this for something else. We have 18 years of data. What is the best and safest method to set the value of this field on all the records, ensuring NO other workflows/scripts run on those records, and the ONLY change is this default value being set? Note that new mandatory fields may have been added to these transactions since they were created and we want to minimise errors in trying to save legacy data.

I don't have a better method, but a couple failsafes if you weren't already intending on doing this: 1. Re: the scripts/workflows, I'd probably go to Script Records and shut off everything for the doc type you're planning on updating, run your thing, then turn them back on a. This would require it to be after hours obviously; maybe that's not an option? 2. I'd not open periods; you should be able to use the "Allow non-GL changes" option if you don't already have it on. That will block any attempted changes that would make the accountants come after you with pitchforks. 🙂

Undeploying all the scripts and workflows is going to be the super annoying bit. I might instead try to set contexts on those.

yeah that would definitely be a PITA if you have a lot of them. I assume you'd have mentioned it if you had access to one, but when I made a similar-ish change to a bunch of old records (going back to 1995!!!), I used middleware, specifically Celigo's tool, whatever that's called now.

You don’t need a Mass Update per each transaction or record type, there are way to write those in a way that would leverage sublist differences.

When I go into the Mass Update tool I don’t see a way to update ALL transactions, it makes me pick a type e.g. invoices

Oh you are going to need a custom Mass Update with some code, but it would be one, that then you will deploy to all the records you would like to update, you still need to create searches to run each one of those.

ah

No, custom mass update are a type of script that you can deploy and run via the Mass Update UI, those are required for complex logic etc…

I don’t think there’s really an advantage to using a script for this. It’s just setting one field to the same value for all.

The advantage is you can have one script to update all the records you need even if they have different sublist IDs, unless you can accomplish that with native Mass Update.

no sublists

If only custom body why not CSV imports?

would override selected form

Is that so? If you import CSV to something that was using a form using another form it would swap the form to the one you selected on the CSV Import?

at least that’s true for custom record…

As long as the field is available (shown) across all forms I would not expect that to happen, you may want to give that a try, because that is by far your easier bet(you can directly exclude the execution of Scripts and Workflows).

let me test on a few records here to see

Well custom records are something different but at least you can solve the normal records via CSV…