#Workflow0 discussing

Hi Brooke,

I'm not sure what the best way to do it would be, but I have 2 solutions.

1. Have the Submitter set the Task Stage back to 'New' or whatever stage alerts the User.

2. Create a custom object and add it to the Lightning Page using the 'Related Record' Component. Then, you can have the submitter fill out that information directly from the Task Record Page. From there, you can either automatically or manually have them trigger an alert.

Thanks,

Nick

Hi @Anthony Dixon,

Currently, Content Documents and related objects (such as Content Document Link and Content Version) are not triggerable using declarative methods (such as a record-triggered Flow). If your use case does not require real-time or near teal-time processing, you could consider using a scheduled Flow to identify records to process on a scheduled basis (perhaps daily). Otherwise, you would need to look at developing an Apex Trigger to fire when a file is related to a record (i.e., ContentDocumentLink). 

We enter almost all of the information that can be known from the check or envelope into Gift Entry in batches. We compromise on only two dates: day of close (check date unless there is a reason to accrue earlier, like postdate of envelope for something extremely late or falling across a book closing boundary, notification of grant or multi-payment donation sufficient to trigger accrual, etc) and date of deposit (payment date planned at bank). CRM batches go hand in hand with deposits of checks. If an offer code can be figured out from the source, we record it. We have a similar process for batches of other types of donations that come in regularly (Facebook). We batch entry of Payapl and STripe even though it comes in daily. We do keep track of the payment source (Paypal, which bank account, Venmo, Facebook, etc). We keep track of payment method (check, bank transfer, cash, gift card, Paypal -- since it's special). We currently trigger each Venmo donation to be transferred to the bank so that it get's handled that way. If a third party is involved in the donation from real people, we record that in a lookup field (e.g., Great Nonprofits, Benevity, United Way, etc.). There is some overlap in third party with payment source. Anyway... getting money is messy. Can't really fix that.

On the accounting side, each transaction is downloaded automatically. Currently we have one transaction per check deposit because we use mobile deposit. If we banked in person it would be a check batch. Currently accounting refers to a report in Salesforce to add names to each named transaction. It's unclear if there is value to this but it doesn't take long (150 transactions per month) and helps with reconciliation and audit.

After the fact, we often redistribute Benevity, United Way, etc in CRM. We do not match that breakdown in accounting. The information to do so comes much later than the payment. But our donors want us to know who gave what so we do it.

Once a month, we reconcile Salesforce as our source of truth (is the term "golden record" now?) for all income. We use the payment date of NPSP payments as the key date and the close amount as the amount. If there are fees taken out, accounting will notice that but we don't fix CRM since the donor thinks they gave the whole amount. (We could approximate the fee at CRM entry time but that's not always easy with bulk and batch fees that are increasingly common.) Accounting is the source of truth for income and expenses and reconciliation to external statements. They do the work each month of reconciling the salesforce report (broken down by payment type and account source) with accounting records. They generate a report that goes to CRM with things like: The following are in accounting but not in CRM: date, person (they can see check images online), amount. We investiage and fix. They also sometimes tell us we have a duplciate or something they can't find. Frequently they are right since they have the oldest and more mature data. They include a record of how much we are off for things like Benefity fees, Facebook fees (sigh... starting in October), Stripe, etc. Paypal actually downloads with fees and gross so that works great.

That's our flow and it's been working for about three years now with about 150 transactions monthly. It requires both a close date and payment date. It requires payment type and channel to sort out weird situations during reconciliation quickly. We're small... the accounting work for our books takes about the same amount of time as our twice weekly payroll administration.

Would it work at 250 transactions per month. PRobably. At 1000 transactions per month... doubtful. But at that scale, you probably would calculate the desired amounts by channel and payment type in the SF report and investigate only the big offset. At that scale it's also doubtful if we'd have one bank transaction per check. It would likely be several weekly deposit batches.

It's all about which you want to be your source of truth. We decided that CRM had to be accurate from the donor perspective and capture sufficient data to be reconciled precisely or by bins to the accounting data. We decided that accounting must reconcile to external financial statements and get sign-off for all differences from treasury. And it must reconcile monthly to CRM and get sign-off from Director or ACcounting and Development for differences (same person in this case). Annually they have to get sign-off from our auditor so the monthly paper trail is crucial, as is diligent corrective action. If it possible to duplciate all the CRM information in accounting (names, addresses, etc) But we didn't see utility to that. We generate our compliance and reporting data for donors and fundraising from CRM.

--Terry