record.submitFields()

documentation shows:

You cannot use this method to edit and submit the following:
    Select fields
    Sublist line item fields
    Subrecord fields (for example, address fields)

Does that mean the only way to set a select field would be to use

record.load, record.setValue & record.save

?

It's just multi-select you cant set, you can set normal single select dropdowns

The field I'm trying to set is a single select dropdown, but when I try

record.submitFields()

I get

"Unexpected Error".

When I try to set a non-select field with

record.submitFields()

, it works just fine

submitFields()

isn't as awesome as everyone thinks, IMHO

@ericbirdsall pretty sure you cannot do the equivalent of setText to submitFields, you'll need to first figure out the value before setting ( I think)

In my case, I have the value already. I tried using both the Text and the Value. The text threw an error along the lines of

"...is not a valid value"

so I'd agree you can't use text with

record.submitFields

, but you apparently can't use values either (if the field is a select field). I went with record.load/setValue/save in my case. It is what it is, I suppose

@ericbirdsall I'm actually quite confident that normal select fields is possible, could you share what kind of list/record field you're trying to set, if it's standard or custom? i'm almost tempted to think it could even be a permissions issue on the list

The field I'm setting is custom and the list is custom, so there may be an issue there(?)

record.submitFields({
    type: record.Type.BIN,
    id: 1213,
    values: {
        custrecord_warehouse_location:"1"
    }
});

Have also tried all combinations of putting custrecord_warehouse_location in double quotes, tried removing quotes from the value of 1 I'm the admin, so I don't believe it's a permission error

why not just load/edit/save the record?

yup, i replicated the error in both 1.0 and 2.0, it's probably at least a defect, but yes, it's not possible in submitFields for me too

@stalbert That's what I did.

I presume your total bin count is pretty small, and load/edit/save will be fast (though takes a bit more governance)

@stalbert not sure how the units fare differently but usually submitFields is cheaper

yes, but I try to avoid premature optimization.

premature optimization may be my new favorite phrase

well, I think submitFields calls under xedit, so I'm more incline to do it if/only just because of that, but that's i guess personal preference?

That's not exactly always true, there are scenarios where you can use record.submitFields (and it works) but it's not an inline editable field, and it actually just uses record.load/set/save for you anyway.

@Sandii in that particular scenario do you know if it was a UE context or WFA context or otherwise?

I'm believe it was actually using record.submitFields on a multi-select field, but this was months ao

I tend towards record load/save because it seems more reliable and consistent in behavior. I want my code to be reliable and consistent in behavior. Only if governance or performance proves to be an issue do I deviate from that (e.g. reach for something like submitFields())