module function · N/action
executeBulk()
action.executeBulk(options)
Executes an asynchronous bulk record action and returns its task ID for later status inquiry.
- Implementation
- Not started
- Design
- Open for proposals suggest how it should read
A
suitescript api
1action.executeBulk({2 recordType: /* string, required */,3 id: /* string, required */,4 params: /* array, required */,5 condition: /* string, optional */,6 paramCallback: /* string, optional */7});
| Parameter | Type | Required | Description |
|---|---|---|---|
| options.recordType | string | required | The record type. For a list of record types, see record.Type . |
| options.id | string | required | The action ID. |
| options.params | array | required | An array of parameter objects. Each object corresponds to one record ID of the record for which the action is to be executed. The object has the following form: {recordId: 1, someParam: 'example1', otherParam: 'example2'} The recordId parameter is always required, other parameters are optional and are specific to the particular action. |
| options.condition | string | optional | The condition used to select record IDs of records for which the action is to be executed. Only the action.ALL_QUALIFIED_INSTANCES constant is currently supported. The action.ALL_QUALIFIED_INSTANCES condition only works correctly if the author of the record action has implemented the findInstances method of the RecordActionQualifier interface. An example of such action is approve on the timebill and timesheet records. |
| options.paramCallback | string | optional | Function that takes record ID and returns the parameter object for the specified record ID. |
B
mynt syntax
No Mynt syntax yet.
Nothing in the language compiles to action.executeBulk(options) today. How should it read?
C
community proposals
Competing syntax for executeBulk, from GitHub Discussions. Select two or more to compare them side by side.
Loading proposals from GitHub…
D
suggest an alternative
Write the Mynt you wish you could write.
A good proposal shows the syntax, the SuiteScript it should become, and argues for it: why it is clearer, how it fits the rest of the language, what it makes harder.
- Clarity. Does it say what happens, without ceremony?
- Consistency. Does it read like
load,saveandRef[field]? - Expressiveness. Does it cover the cases people actually write?
- Honesty. Does it hide a NetSuite cost, such as governance, that a reader should see?