Check the “Custom Code” tab of the Custom Form definition; there may be a script attached to the Form itself, which is what I am inferring from the `customform (postSourcing)` line of the error message.

Whatever that script is doing during the postSourcing event, it is attempting to set a sublist column with a nullish value.

Have you read/tried the approach defined in `Help:Creating Custom Fields with Values Derived from Summary Search Results`?

Nothing native that I’m aware of. You’ll likely have to build a customization to handle this; either a script or a workflow. Perhaps maintain a custom field on the Employee record or a custom record which maps Employees to their record instance, then verify on beforeLoad that they are not trying to view someone else’s record.

Try printing all the keys of result to find your answer:

<#list result?keys as k> ${k} </#list>

While I’m not specifically familiar with Sheet, any AMD-compatible module should work with server-side SuiteScript. Exceptions will be modules which depend on browser APIs like window or document etc.

When trying to trigger a User Event from another User Event, the Suitelet in the middle strategy is a very common one, so you’re on the right path. However, you don’t need to *redirect* to the Suitelet unless the Suitelet has some sort of UI for the user to interact with. Instead, simply use the N/https module to send a POST request to the Suitelet from your original User Event.

On the other side, you can display the native confirmation method exactly as in your screenshot by using a beforeLoad event and calling the  showPageInitMessage on the Form object attached to the context parameter of the event handler. See the API docs in Help for how to use this function correctly.

You’ll want to add a checkbox field to the record type. Leave it unchecked by default, and check it once your processing is complete. Add a filter to the saved search to only look for those records with the box unchecked.

You can try using Freemarker’s Date/Time Format Settings: https://freemarker.apache.org/docs/ref_directive_setting.html#topic.dateTimeFormatSettings

I haven’t tested this myself, but you can try to add a settings macro somewhere in the template like so:

<#setting date_format="MM-dd-yyyy">

I’m not sure there is a way to know this without some thorough experimentation on your part. It’s certainly not documented anywhere. Workflows are just a UI for SuiteScript; when you save a Workflow, SuiteScript is generated for you behind the scenes, so the primary differences are mostly going to show up in the opimization of the generator’s SuiteScript versus your own.

I’m not sure there’s any difference on the NetSuite side between loading up a Workflow and loading a Script because they’re essentially the same.

At any rate, I never advocate trying to optimize performance too early. I wouldn’t worry about it unless you can definitively prove there is a significant difference causing your users noticeable pain. Here’s a video I did with Matt Dahse discussing other Workflow vs Script considerations: https://www.youtube.com/watch?v=DfoiE_0yNVg

Most sublist data is not available to Workflows at this time (2019.1). Only Transaction Item sublists are currently available. More are in development for future releases.