Congratulations Salesforce Nonprofit System Administrators on completing another year! Now that the focus is on generating end-of-year donation letters, here's a list of some innovative solutions implemented by Sys Admins working with Salesforce NPSP and iDialogue. We're constantly amazed at the creativity and ingenuity of Sys Admins and Developers at Nonprofits.
Tip 1: Create a Variety of Donation Letter Templates
Daniela Cruz, Administrative Program Assistant at Reading Power Inc., has accumulated several personalized donation letter templates, one for each Donation type, that she can generate, print, or email with just one-click.
Daniela's screen flows also auto-update Acknowledgement Status and Date fields on Opportunity records.
Tip 2: Personalize Donation Acknowledgement Letters
Utilize NPSP fields, like Formal Greeting and Informal greeting in letter templates. Add a signature image of the Nonprofits CEO, Founder, or Director.
4 Word doc donation letter templates are included in the iDialogue NPSP accelerator package, with pre-defined merge tags.
Tip 3: Create Separate Donation Letter Batches for Print and Email
Tip 4: Generate Envelope Labels From Salesforce
Tip 5: Generate Letters From Custom Objects
One of many pre-built iDialogue screen flows included in the NPSP Accelerator package.
We take the security of iDialogue very seriously and actively monitor broader Internet security trends and bulletins.
For those with questions related to the log4j vulnerability,this post provides some details on proactive and preventative measures taken to ensure the security of iDialogue hosted data and documents.
Our hosting provider, AWS, has assured us our Java 11 hosted containers were not exposed to this vulnerability, and that they've taken the following additional preventative measures:
AWS Lambda does not include the Log4j2 utility in the Lambda Java managed runtimes (Java 8, Java 8 on AL2, and Java 11) or corresponding base container images. Functions that do not include impacted versions of Log4j2 within their code are therefore not affected by the issue described in CVE-2021-44228 and CVE-2021-45046.
We have applied a change to the Lambda Java managed runtimes and base container images (Java 8, Java 8 on AL2, and Java 11) that disables remote class loading by the RMI Registry or COS Naming service provider. This change helps to mitigate the issues in CVE-2021-44228 and CVE-2021-45046 for Lambda functions that package the impacted versions of Log4j2. Customers using managed runtimes benefit from this change automatically.
iDialogue has one transitive dependency on Log4J via our use of the Twilio Java SDK for sending SMS messages for two-factor authentication to rooms. In addition to upgrading this dependency to Log4J v2.17.0, we’ve also verified the utilization of the SDK does not log customer provided events.