0

I have created a trigger that validates user input against a web service after insert/update. Originally, I wanted to show a validation error on the data entry screen, but this is not possible due to @Future methods not being supported in triggers.

I know that I could create a new lightning component to handle this validation, but would prefer not to. The preference would be to continue to leverage the native LEX UI, and instead notify the user via a popup, update in the notification area (in the top right corner), or a toast message. Is this possible? If not possible, what is the path of least resistance/lowest customization?

Improve this question
0

Let's think architecturally how Salesforce is designed. We cannot do dml and callout in said sequence in one transaction.

Thus we use the future/queuable functionality of Apex. There is no SLA for future/Queuable. They will run in the near future, It can be in 10 seconds or can be 10minutes or an hour. There is no guarantee that it will be executed in said duration.

Now coming back to your question, It can happen that your user has logged off or closed the browser window when the future method ran, thus tying it to UI component doesn't make any sense to me. A better way would be to update the error some record as error status so that You can send a Workflow email or create a task and assign it to the user who created it. Adding a listview with a proper filter can also help you achieve this.

If something like push notification/popup is your requirement, you can create a lightning component using lightning:empAPI and add it to the App layout using App builder. Now and fire a platform event when an error occurs in your future method, you component will listen to that event and then show the toast /error message accordingly.

Src: https://developer.salesforce.com/docs/component-library/bundle/lightning:empApi/documentation

Improve this answer
7
  • 1
    Just a word about this approach though. When you subscribe to Platform Events you cannot filter the subscription (the front-end needs to filter to decide what to act on). That means this doesn't scale well with a lot of active users when there are a maximum limit of 50,000 delivered event notifications per 24h shared by all CometD clients. If 50 users are on this page all at once and trigger the same call, they will all receive each other's events and you'll use up 2500 of that limit. In smaller orgs not a problem though. – Charles T Sep 17 '18 at 20:36
  • I kinda read that there is no limit in subscribing to platform events in the SF platform, external cometD usage is counted in limit... – Pranay Jaiswal Sep 17 '18 at 20:40
  • Interesting. Do you have confirmation on this? I'd interpreted all CometD including internal. Also to the OP, please be aware lightning:empAPI is a Winter '19 component not available to production orgs until mid-October. – Charles T Sep 17 '18 at 20:41
  • So the documentation says, Subscribers on the Lightning Platform (non-CometD clients including Apex triggers, processes, and flows) don’t count against the 24-hour CometD event delivery limit. The number of event messages that an Apex trigger, process, or flow can process depends on how long the processing takes for each subscriber. The longer the processing time, the longer it takes for the subscriber to reach the tip of the event stream. It doesnt tell about empAPI cause its not yet updated I guess, I belive we to post in Events chatter group to get more insights. – Pranay Jaiswal Sep 17 '18 at 20:44
  • The API 44 document doesn't say any differently. The lightning:empApi component is definitely CometD under the covers - it is not a trigger, process or flow. So I would assume it does count against the CometD limit. – Charles T Sep 17 '18 at 20:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.