Is it possible to set Multiselect Field using record.submitFields ??

I believe so, what is the syntax of the value you are trying to set/

On a project record we have multiselect field which has three values. But when i used record.sumitFields the multiselect field is not setting to any values.

I dont believe Multi-Select fields are inline-editable, so technically NetSuite would NOT support the use of record.submitFields() against them even if it does work in practice.

Yeah does not seem to be working for me on a random field from teh chrome console.

Do it serverside

I think it can be done. Can you send the statement you are using?

Multi-Select fields are not inline-editable, therefore there is no benefit to using submit fields against them vs loading and saving the record. Governance Implications When you use nlapiSubmitField(type, id, fields, values, doSourcing) as it is intended to be used (to set one or more fields that are inline editable in the UI), the SuiteScript governance cost is 10 units. However, when you use nlapiSubmitField(...) to update fields that are NOT inline editable in the UI, the unit cost for nlapiSubmitField(...) is higher. Your script is charged the units it takes to load and submit a record. For example, the unit cost of nlapiSubmitField(...) to set a non inline editable field on a transaction is: 1. load the record (nlapiLoadRecord) = 10 units 2. set the field = no units 3. submit the record (nlapiSubmitRecord) = 20 units Total = 30 units

record.submitFields is 10 units only on transactions (this person is not trying to submit a transaction), and there would be a benefit if they are already using submitFields to set other field values purely from convenience/concise code

You missed the point of my message. NetSuite allows you to use submitFields() against fields that are not technically inline-editable in the UI. When you use submitFields() on a non-inline-editable field, the server actually has to load and save the record anyway, so the additional governance cost of that load and save is incurred in that instance. You are welcome to read more about it in help, just search for: Consequences of Using nlapiSubmitField on Non Inline Editable Fields

Most people are not concerned with governance usage when trying to update a record, that is my point.

It would matter if you were trying to update a number of records. In this case it sounds like governance is not an issue.

Well it would be a bad practice to use it in that instance, because it will not be behaving the way it looks.

I would be curious know what the context is on the backend when it uses the load, set and submit for you, edit I assume?

yes, I believe it is edit context. * EDIT: Incorrect *

@Sandii it worked to me when i used in User Event. But it is not working in chrome console.

@Sandii I was mistaken, the context WOULD still be xedit in that case. Sorry for my confusion, couldnt remember all the weird specifics.

yeah its a really weird one

Clientside ss2 submitFields doesnt work with multiselects

^

Context for this is both view and edit. In AfterSubmit function, based on the each selection of the multiselect field I am creating a new task record. so in order to avoid recreating the task on every edit, I am checking a new field for the proof of task creation. So the use case is that users will select one field at a time on each edit which means the value previous select will be erased even though there is a task against the value selected. So when ever this happens based on the number of created task i need to reselect the multiselect fields values.

That sounds horrible performance wise

yeah I added a temporary field. Thanks

@Sandii how do you check how much governance you use?

@Gail Kasnett runtime.getCurrentScript().getRemainingUsage()

thanks