Date: 8th Aug 2022
1. Issue: The user was facing an error related to the consent object for an opt-out functionality in the error log
The Admin user was receiving an error “Procedure is only valid for System.DMLException and System.MailException” in the error log object. This occurred when the “WhatsApp opt-out” checkbox was enabled from the record page and a consent record was updated for the mobile number to Opt-out. The consent record was getting created; however, this also generated the error log.
The issue related to the consent object for an opt-out functionality is now resolved.
Date: 16th Dec 2021
1. Issue: SMS-Magic mobile users were able to send SMS to leads even before obtaining their consent.
The customer had created a test user and provided the consent for testing purposes. The customer was using CustomConsentService class to validate consents. In SendSMSTriggerHelper.sendSMSBeforeTrigger(), the ConsentService.getConsentValidatedRecords() method was called to fail records on the basis of consent. The injection point was provided in this method. Messages were getting failed in the custom class and were returning to the list mobileApplicationSMSList in SendSMSTriggerHelper. As CustomConsentService was used, the list was sent and processed in a serialized form. In the process of serialization and deserialization, the reference was not followed and mobileApplicationSMSList was treated as a different list from smsList which is the main list. This main list was not getting updated.
To solve this issue, main list was updated as per the updated mobileApplicationSMSList in SendSMSTriggerHelper.sendSMSBeforeTrigger().
Date: 3rd Dec 21
- Issue: Channel ID and Sender ID were not mapped.
Fix: While sending the message, the customer user was getting the following error, “Channel and Sender ID are not mapped’’. The Sender ID was added to their production instance and the customer had created a record of that Sender ID in their Sandbox instance. The issue was occurring randomly. Some of the messages that were sent through the Sender ID 447418344628 were delivered and some of them were failing.
While checking the debug logs it was found that the MessageDetailsUtility.PreparedUnifiedPayload method was creating a payload. This method was called MessageDetailsUtility.GetMessageDetailsList method where the channel code was being worked on, depending on the `Channel Name template ID’.
Here, the MessageDetailsUtility.getTemplateMetaMap method was called and inside this method, it was executing 1 query on smagicinteract__Template_Channel_Map__c & inside the clause it was fetching records from template ID.
This query was fetching 1 record, that tried to run the same query in the dev console island and it was returning 0 records, which was correct. It was suspected that the one record-receiving of type was WhatsApp channel Type.
To solve this issue, Added (smagicinteract__Channel_Code__c ==2 || smagicinteract__Channel_Code__c ==3) condition and thus it was a part of MessageDetailsUtility.getMessageDetailsList method.
Date: 16th Nov 21
- Issue: Customer was facing Component Error
Fix: The customer had reported that their users were getting the component error while opening the lead record. This error was intermittent but it was affecting the user experience.
License and permission sets were already assigned to the users. Component Error occurred because push topic subscription was not successful for the affected user.
To solve this issue a Null check-in ‘ProcessMessages’ method of conversationComponentController was created.
- The Customer was facing an issue with incoming notification with an email setting
Fix: In the Sender ID step of converse settings, ‘Email notification on incoming (Default Setting)’ was configured.
The logic in the ‘SendEmailBySender ID’ method of SMSUtility.cls was not correct. If any specific Sender ID record did not have the ‘Send Notification From Email’ value populated, the code was not picking up the default configured email address. Thus the email was sent from the Admin user’s email address.
To solve this issue, the logic in the ‘Send Email By Sender ID’ method of SMSUtility was updated to populate default values from `Global Setting’.
Date: 03rd Nov 21
- Issue: Whatsapp 24 hours window was not working
Fix: The client was sending MTM templates to their international number. While receiving incoming SMS, the conversation window for WhatsApp SMS was still showing as blocked for the user. Once we received the incoming SMS, it allowed the users to send the messages in the next 24 hours.
Whenever we tried to send a message from the conversation view on the record detail page. We checked for the valid duration and if it was applicable we call this method ‘Channelutility.checkForValidDuration()’. Inside this method, we checked if the Record ID is not null, and we fetched the incoming messages. To fetch records from SMS History we had a method ChannelUtility.getLastIncomingTimeIntervalForSMSHistory(). Here, we executed 1 query on SMS History which fetched incoming records from SMS history using the phone field.
Here, the phone number we were using consists of all the characters other than numbers (Like +, -, etc). We were not removing those unwanted characters. That’s the reason why it was not fetching any record in the query. That’s why the 24hrs window was not getting enabled.
To solve this issue Added a call to MessageUtility and removed the LeadingZeroes() method which will remove all the unnecessary characters other than a number.
Date: 14th Oct 21
- Issue: The customer was facing an issue with Automated Messages as they were getting failed
Fix: Most of the Automated messages were getting failed and the customer was receiving multiple error log records. They were getting an error ‘Selected Sender ID is not valid. Select another Sender ID and try again.’
Also, there was an error when Converse settings was clicked. Whenever a user tried to send a message using Record Owner’s Sender ID, and some of the records owners didn’t have Sender ID assigned then it was throwing an error ‘Selected Sender ID is not valid. Select another Sender ID and try again.’ SMS History record was also not getting created.
To solve this issue, try-catch block in Senderservice.resolveandAttach() method was added.
In the try-catch block, the issue regarding invalid Sender ID was resolved and thus the customer was able to send automated messages properly.
Date: 22nd Sept 21
- Issue: Converse Bulk Campaign was stuck in the running state
Fix: Whenever the customer was trying to fetch the Listview records that were created, a query in the Metadata Service.ParseSelectCondition() popped up, which split into 2 parts.
Part 1: On the right side of the keyword ‘FROM’
Part 2: On the left side of the keyword ‘FROM’
Here, whenever the user created a list view with criteria that contained a lookup of another object, the query contained 2 ‘FROM’ keywords in it. The code was taking 2nd FROM keyword and was getting split into 2 parts. This caused a returned query that was running on the lookup object and was causing the issue.
To solve this issue the object name was fetched and divided the query from keyword ‘FROM’ + object name into 2 parts. 1st part consisted of values FROM Object name & 2nd part consisted of the where clause.
- Issue: Customer was facing future Callout from process builder
Fix: An IncomingService.pushNotificationsToMobile() was called in the conversationTriggerhelper class after a conversation was created. A callout was created while the conversation was in the same callout IncomingService.pushNotificationsToMobile().
To solve this issue, temporary changes regarding pushNotificationsToMobile() were not certified due to platform issues. The changes were reverted and final changes were made once all the issues from the platform side were resolved.
Date: 13th Sep 21
- Issue: Customer needed a Patch Version for 1.64
Fix: The client had the requirement to implement the custom component created for Intake, Matter, and Party. For this purpose, the Composer Component needed to initiate independently fetching the required data. To solve this, the condition in the init of the composer component was updated to fetch the required data when it did not pass from the parent component and added the ‘had access’ attribute while creating the composer component and passed its value as true.
Date: 1st Sept 21
Issue: Post upgrade issues from 1.58 to 1.64.30. (Customer was facing the conversation component error on the opportunity record and also the browser was running slow)
The user faced the below issues after upgrading from 1.58 to 1.64.30.
1.Admin user was getting an error when he opened the Conversation component on the opportunity record.
2.The users faced issues where their browsers ran very slow and sometimes froze.
The user had a custom push topic event implemented on the record details page of the opportunity object. The subscription error of that custom event was captured in the streaming data service component of the package. Because of the error, the connection flag value of the component was set to false, and the component fallback to a continuous polling mechanism instead of a push topic subscription. The Apex calls are part of continuous polling, causing the page to hang until the apex call is resolved, thus hampering the user’s interaction with the page.
Added check-in callback handling of the error and checked whether it’s a subscription error of the push topics created via package and not any other push topic event that would have been present in the target org. Also, we partially removed the conversation utility bar to lower the freezing time.
Date: 25th Aug 21
- Issue: The customer was facing an issue after the upgrade from 1.58 to 1.64.30
1. Admin user was getting an error when they open the Conversation component on the opportunity record.
2. Users were facing issues where the browser was running very slow and it was freezing sometimes.
The issue was fixed after removing the Conversation utility bar.
The customer wanted to use the Conversation utility bar, however, didn’t want the system to run slowly.
The customer had some custom push topic events implemented on the record details page of the opportunity object. Thus the subscription error of that custom event was captured in the “StreamingDataService” component of our package. Because of that error, the connection flag value of the component was set to false and the component was falling back to the continuous polling mechanism instead of push topic subscription. Apex calls, which were part of continuous polling, were causing the page to hang until the apex call was resolved. This was hampering the user’s interaction with the page.
To solve this issue, a check-in was added to check whether the error was for the subscription of the PushTopics created via package and not for any other PushTopic.
- Issue: The customer was facing a Non-selective query against a large object error
Fix: The customer was facing an error non-selective query even after indexing the fields.
This query was arising when they were trying to send automated SMSs through the converse app.
While querying on SMS history records in fetchMonthlyMessages method of ConsentService class, it was throwing an exception because the team was using ‘status != and template!=null’ in the where clause.
Whenever the customer was using P+S compliance, messages regarding content type were getting fetched. This was fetching multiple records using queries & was causing unnecessary code execution for P+S compliance.
To solve this issue, changes were made in the query. The ‘status in (status set) and Is_SMS_Template_Empty__c = false’ condition was removed from both places and added a check to see if the customer was using Content-Type in compliance. If the customer was using Content-Type then added a check & called fetchMonthlyMessages() method.
Further, in v1.65.35. The particular query was supposed to be executed only if the content type was a part of compliance parameters. Thus added the check-in ConsentService class if content-type was enabled for compliance and only then executed the query.
Date: 20th Aug 2021
- Issue – Unnecessary continuous debug logs were getting created in the Dev Console
In the developer console, there were unnecessary debug logs getting generated from SMS-Magic.
The periodic polling mechanism was generating continuous logs. This call should not have been made for non-licensed users.
To solve this issue, a license check was added in the method ‘conversationsWrapper’ of MessageComposerServreController.cls. and access check was also added in conversationsComponent before calling apex method to fetch the latest messages.
Date: 06th Aug 2021
1. Issue: Non-selective query against large object error.
The customer was receiving the error ‘Non-selective Query’ even after indexing the fields. The query was arising when they were trying to send automated SMSs in the converse app. While querying on SMS history records in the ‘FetchMonthlyMessages’ method of ConsentService class, it was throwing an exception because ‘status != and template!=null’ was used in the clause and to solve the issue. Changes were made in the query. To solve this issue, the method ‘status in (status set) and Is_SMS_Template_Empty__c = false’ was added. != condition was removed from both places.
Date: 02nd Aug 2021
- Issue: The fallback Sender ID set for action was not consistent with the UI of the Converse App action
When a customer was trying to update the Sender ID on the UI of Converse App Action, it was getting auto-updated to the old one. Existing functionality was that while fetching Sender IDs based on SenderId value rather than Record Id, we were assigned the first element of the list to that Sender ID.
If an org contains Sender IDs with the same alphanumeric value, it was producing a list of Sender IDs with more than one value, and each time the first Sender ID was getting assigned to Converse app action.
The proposed solution was that instead of fetching Sender IDs based on values, now it would be fetched based on Record Ids, so that every time a unique Sender ID will get produced.
- Issue: Unable to Send MMS Via Bulk SMS button
The customer was facing an issue where the users were unable to attach media while sending messages via the Bulk SMS Button.
To solve this issue, implemented negation for the ‘AllowToChangeTemplateSelection’ variable.Negation for attribute ‘AllowToChangeTemplateSelection’ was missing in the ‘class’ attribute of the button element. A class with the name ‘slds-is-disabled’ was getting assigned to the button element thus the button was clickable yet shown disabled.
Date: 2nd July 2021
1. Issue – Unnecessary Continuous Debug logs were getting generated in the dev console
In the developer console, unnecessary debug logs were getting generated from SMS Magic. These continuous logs generated by the SMS Managic managed package were observed and prompted by the customer.
It was analyzed that the periodic polling mechanism generated these continuous debug logs in the dev console.
Resolved this issue by adding a license check in the conversations wrapper method of the message composer server controller class and by adding an access check-in conversations component before calling the apex method to fetch the latest messages.
This issue of continuous debug logs in the dev console is now resolved.
2. Issue – The email-to-text feature was not working for the customer.
The user was facing an issue where their email-to-text configuration was not working as expected. Previously when they were replying to the email notification, they could leave the Reply-To address field blank, which caused the individual users’ notification reply service email address to populate when they replied to an email.
Now, when the user hits the Reply on the email button, the notification reply service email address is that of CRMAdmin, which is set up only to receive emails from assigned mail (CRMAdmin). If we add all users to this notification reply service, the text messages created by the incoming email will be owned by CRMAdmin, and all further notifications will go to CRM Admin.
Executed the DML operation in the admin user’s context; by default, the current user was the owner of the SMS history record. The user id is set to the owner id for the missing user for a newly created SMS history record. Queried the user id based on the from address attribute of the incoming email and ensured the user who replied to the email would be the owner of the SMS history record.
The error related to the functionality of email to text is now resolved.
3. Issue – Salesforce campaign issue occurred when the user ran the campaigns with more than 5000 contacts
The user was facing an issue while running large Salesforce campaigns. The user created a salesforce campaign, sending messages to 5000 (approx) recipients; however, when they were clicking the Run SMS Campaign button on the Campaign record, it was throwing the Apex CPU time limit exceeded error.
The issue occurred when the user ran the campaigns with more than 5000 contacts. Previously (before upgrading to 1.64), the user was able to schedule SMS for 25,000+ contacts in one campaign.
The enabled new compliance message utility functionality was inside the ‘for’ loop. Internally, this method calls Security.hasAccess(); if there are 22k campaign member records, then both methods will get called 22k times, which is time-consuming.
We have stored the result in one variable and would use that variable wherever necessary.
The issue related to the Salesforce campaign is now resolved.
4. Issue – Customer was facing bulk SMS component error and bulk button issue on LWC.
When the user was opening a custom widget and clicked on the Send SMS button, no list was shown, and no record was selected.
After selecting a record from the listview to send Bulk SMS, sometimes the records were passed without the ‘[‘ ‘]’ brackets. Also, it was observed that as the ‘[‘ & ‘]’ brackets were unavailable, removing characters from record ids caused the issue.
We analyzed and removed the first & last characters from the array.
The normal bulk SMS from any List view of any object and the bulk button issue on LWC is now resolved.
Date: 14th June 2021
- Issue – Issue of SMS getting sent to duplicate number in Converse App >> Bulk Campaign
ID of the converse app task was not passed to batch before execution. Thus the required check for duplicate numbers was not happening.
To solve this issue, the ID of the Converse App task was passed to batch ensuring check for duplicate numbers. With this, sending messages to duplicate numbers was avoided.
- Issue – Need to pass the record ID parameter to the injection service:CustomConsentService
The client wanted to check for field on the record and based on that they wanted to manage the Consent record. For customization, the case record ID was required to be passed to the custom class (“CustomConsentService”) at the injection point.
At the injection point, the record ID was passed to the custom class (“CustomConsentService”) to support the customization case.
Date: 2nd June 2021
- Issue: The SMSs were not getting pushed in SF due to excess SOQL queries.
The incoming SMSs were not getting pushed in SF due to too many SOQL queries.
It was analyzed that when the toggle for notification on incoming SMS was Off, SMS messages were getting pushed, and if it was On, the user was receiving an error.
The issue related to the error while pushing the toggle for notification is now resolved.
Date: 24th May 2021
- Issue: Customer was getting an error while sending SMS from Bulk Campaign from the Converse App
When any object from parent-child relationship was configured in the Message Configuration Object (MOC), the package code was not able to resolve the relationship to get the value of the opt-out field. Due to this, the customer was getting an error while sending SMS from Bulk Campaign from the Converse App.
To resolve this issue, the code was updated to resolve the relationship and get the value of the opt-out field as expected.
- Issue: Customer was facing an issue with lookup object on SMS consent record
The last updated record ID was getting attached to each consent record that was created. This was causing the mentioned error.
To solve the issue, the unique record ID which is fetched from input consent data was updated.
Date: 17th May 2021
Fix: Conversations Lightning component was not loading messages properly. The customer was facing an issue where the messages before 16th march were not loading on the conversation component on the record page layout. In message.cmp there was an unnecessary use of the method sanitizeUrl() that was causing an issue while parsing the object instead of a string.
To solve this issue, we removed the unnecessary use of the method. Used it at a relevant place from a security perspective.
Date: 5th May 2021
- Issue: Customer asked for customization for SenderId Injection point
Fix: Customer wanted Sender IDs to be available in a specific sequence.
In the injection point, the data was run through the “transformData” method which was causing an issue in implementing the desired customization for the customer.
To address this customization requirement from the customer, an ‘IF’ condition was added where a deprecated flag ‘smagicinteract__Canned_Responses_Only__c’ from the ‘globalSetting’ was used. If it was true then the data was not transformed, if false, the functionality was executed as usual.
- Issue – Consent was not getting created for SMS channel via process builder
Fix -Customer had configured a process builder named “Lead Driven Processes on Lead” to create consent for SMS and WhatsApp channel when the conditions were fulfilled. This was done by the apex class coming with the managed package.
It was working fine, the customer could see that consent entries were getting created for the SMS channel till 17th March 2021.
Later, it only created consent for the WhatsApp channel.
The customer could see an entry created under the error log at the same time with an error “Attempt to de-reference a null object”.
- Issue – Consent was not getting created even when the criteria were met
Fix – A process builder was created for consent creation that calls apex” smagicinteract__ConsentService”, when the criteria of the checkbox “Consent to contact via Whatsapp” getting checked was met. But the number in the WhatsApp number field was not opted-in (Condition 2 and 3 in the process builder)
- Issue –
When any user was logging in and selecting any Sales or Service Path where the utility bar component was assigned, the tab at the top showed “Converse Desk|SMS-Magic”. The client users were getting confused with this and so the client wanted this to be resolved.
Misspelling in the error message that was getting displayed.
If the user does not have any license then they were getting an error message, “You don’t seems to have required license to send SMS or MMS”.
Here, in the error message, there was a spelling mistake; it should have been ‘SEEM’ and not ‘SEEMS’.
The ‘Send SMS’ button was configured on Lead, Opportunity, Account, and Case object. When the customer user was clicking on the button, it was not fetching the mobile number to send the SMS.
If the VisualForce pages assigned to the Send SMS button were edited and the phone fields were added to it, it was fetching the phone info. However, the client did not want to add any manual steps to update the VisualForce page script.
As per logic, the Send SMS VisualForce pages should have displayed the phone fields configured in the MOC, however it was not working.
Issue 1 – Added a condition in ConversationView to skip the execution of setting title if SF1 was not found in the context
Issue 2 – Custom Label was changed
Issue 3 – Removed the condition from LightningBulkSMSController which was limiting the selection of Phone Field from MOC configured.
- Issue – Issue with Lightning Tab and with Send SMS button
When any user logs in then selects any Sales or Service Path where we have assigned the utility bar component, the tab at the top shows “Converse Desk|SMS-Magic”.The user are getting confused with this and client wants this be resolved asap.
Lightning app name: Sales Path (Sales Management app for Lead Gen)
We have configured Send SMS button on Lead, Opportunity, Account and Case object. When we click on the button, it is not fetching the mobile number to send the SMS.
Date: 24th Feb 2021
Issue – The 24hr Conversation Window was not working properly on Facebook and WhatsApp
The 24hr Conversation Window was available on One record with the same mobile number and Sender ID. However, it was not available on another Object. The system was checking for the 24hr window on the basis of recordID, phone, Sender ID, and channel. The recordID was causing the issue.
To solve this issue, recordID was removed from the key. With this, the 24hr Conversation Window started functioning properly on WhatsApp and Facebook both.
Date: 20th Jan 2021
Issue – The consent records were not getting created with country code prefix
Consent records were not getting created with country code prefix for those who have set a specific country as messaging destination (other than the ‘All’ option). Consent records and compliance enforcement functionality was not working as expected.
To solve this issue, security enhancements were done in the country-specific consent recording.