Hello. I'm one of the developers of a SuiteApp that has been in the marketplace for more than 10 years. For nearly all of that time, we have been utilizing the "Suitelet workaround" for triggering User Event scripts on one record as the result of changes made from a User Event script on another record. In other words, calling a Suitelet from a User Event on record A to trigger the creation/update of Record B in order to ensure that its User Event script(s) are triggered (since one UE script cannot trigger another UE script, directly). This approach is documented in SuiteAnswers as a recommended workaround for this issue. However, we are recently getting a lot of pushback from NS about utilizing this approach in our SuiteApp, as it requires that we enable the "Available without login" option on the Suitelet script (since the calling UE script cannot provide the user session information required to invoke the Suitelet otherwise). Unfortunately, NetSuite has, thus far, been unable to offer us a viable alternative that would allow us to still ensure that all UE scripts on the target record are triggered (synchronously) when changes to that record are initiated by a UE script on another record. Are there any clever people out there who might have any ideas about this?

I'm curious, how is that possible that you cannot provide the session information from a UE to the suitelet?

@BrandonJSmith https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_44162330742.html

This method can only return an internal Suitelet in trusted contexts for authenticated users. http.requestSuitelet(options) can no longer be used to perform outbound HTTPS requests in an anonymous client-side context, such as for shoppers in a Web site. The options.external parameter is removed as of July in NetSuite 2024.1.

What does this ^ do in say a Map/Reduce where there is no "authenticated user"?

@eminero for whatever reason, User Event scripts (along with other server-side scripts) do not actually run within the context of an "authenticated user". This is why our only option so far has been to enable the "Available without login" option on the Suitelet. Otherwise, our calls from User Event scripts fail.

could you use the n/Task module to trigger a non scheduled or MR script to the the record update / create?

I think that should be possible but let's say that it is not. have you tried moving your logic to a restlet? I'm pretty sure you will be able to pass the necessary session info to call it.

@//greg absolutely, we could. But then we're at the mercy of the processing queue for when those tasks are actually completed. We are trying to provide "real-time" immediate completion of the processes in question.

Yeah, you are right related tot he concurrency limitation. Related to the integration record, if at the end of the day, the suitelet cannot be called from a UE script with the sessions values, you might need to adjust your architecture in order to keep working your SuiteApp, or to get the approval to continue distributing it. I would be curious how you ended solving this.

Thanks. Yeah, that's exactly the spot we're in right now. Fighting with NS to try to get them to allow us to continue doing things the way we have been for 10+ years, in order to keep our BFN certification. 😕

Just to provide some info, NetSuite's own Electronic Banking Payments suiteapp does the same thing

Re-architecting all of the code around these processes would be a nightmare at this point. And that STILL would not solve the problem of ensuring that customers' custom UE scripts are still triggered when our product creates/updates those records. 😞

Yes

What's the name of that app?

Electronic Bank Payments 509148

Thank you!!

I DM'd you. I also do the same thing in my suiteapp and they haven't said I couldn't, only to use a role that is not admin

@ehcanadian thanks. Is your SuiteApp BFN-certified?

Yes, native

Well, I hope they leave you alone. But be prepared in case they don't. 😞

If what you want to do is a workaround for UE not triggering UEs I have seen people use non-initiating workflows with workflow action/ workflow action scripts So suppose you deploy a non-initiating workflow on record B, have a flag or something, use the N/workflow module, and use workflow.initiate on a record A UE, to initiate that workflow on record B Then with your record B UE enabled with workflow context, the UE will then be trigger on record B by the workflow.intiate A few cool things with this setup is your record A could run async, so it'll load faster too... so the idea is UE deployed on record A trigger-> WF deployed on recordB (with some kinda trigger say after submit hit a flag)-> UE deployed on record B will trigger from said flag and then unflag

@Timothy Wong hmm. That's an interesting idea. Would I need to callout specific UE scripts that would be able to be triggered by this workflow? Or could it be configured to simply trigger ALL UE scripts that are deployed to the record? Since we have customers who add their own UE scripts to various records, we need a solution that triggers all of the UE scripts on the record. Also, would it still be executing all of the normal entry point functions for those UE scripts (beforeLoad, beforeSubmit, afterSubmit)?

@BrandonJSmith yup, so maybe you could have a workflow action script that just does record.load and record.save on entry instead, then it would trigger ALL the UE scripts on record B