Overview

This tutorial explains the end-to-end workflow for managing High Holiday honors in Shalom Cloud:

• Importing honors from a provided spreadsheet format (initial year)
• Copying honors year-to-year (subsequent years)
• Configuring honor statuses (e.g., Offered, Accepted, Declined)
• Assigning honors to congregants
• Using queries to send offer and reminder communications
• Updating statuses as responses are received
• Leveraging year-based history for reporting and future planning

Prerequisites

Before assigning honors, complete these setup steps:

1. Prepare the honors spreadsheet in the required format.
2. Configure the honor statuses your organization will use.

Honors Spreadsheet Setup (Initial Year)

At the start of the year, provide an honors spreadsheet in the format Shalom Cloud supplies. Each honor record should include:

• Honor name
• Honor description
• Prayer book page number (start)
• Ending page number (if the honor spans more than one page)
• Service start time
• Service name

After the spreadsheet is prepared, upload it into Shalom Cloud.

Year-to-Year Maintenance (Subsequent Years)

In later years, you typically do not need to rebuild honors from scratch:

• Copy honors from the prior year to the new year
• Adjust as needed (add new honors, remove obsolete honors, edit descriptions/pages/service info)

Configure Honor Statuses

Set up the statuses that will track each honor’s lifecycle. At minimum, include:

• Offered (important for initial outreach and pending responses)
• Accepted
• Declined

Optional examples (commonly useful):

• Accepted (In-Person)
• Accepted (Virtual)
• Rejected (if you distinguish it from Declined)

Choose statuses that match how you communicate and how you want to report.

Assigning Honors

Navigate to:

• Maintenance → Create and assign honors

You will see the list of honors for the year and can assign each one.

Assign an honor (search by name)

1. Select an honor and open it for editing.
2. If you have a specific person in mind, type part of their last name.
3. Run the search and select the correct congregant record.

Assign an honor (using filtering and a pick list)

To choose from a filtered list rather than typing a name:

• Filter by criteria such as Active and Adults
• Optionally exclude people who already have an honor assigned (to reduce duplicates)
• Run the search to display a pick list

Assign to one or multiple people

Some honors may be assigned to more than one person (e.g., paired readings). Select the applicable people and use the Assign action to confirm.

Setting the Status During Assignment

When assigning, set the status based on whether the person has already confirmed:

• If you already know the person will do it, set the status to Accepted (or Accepted In-Person/Virtual).
• If you are offering the honor and awaiting an answer, set the status to Offered.

After choosing, use the Update Status action.

Communicating Offers and Reminders Using Queries

Shalom Cloud uses queries to pull lists of assigned honors for communication (email or hard copy).

Navigate to:

• Queries → Honors

Send offer communications

1. Filter by status Offered (or “Offered / Not yet answered”, depending on your configuration).
2. Optionally narrow the results:

• By service (e.g., Rosh Hashanah Day, Kol Nidre)
• By page number (useful for page-based planning)
• By person name (to locate a specific congregant)

1. Use the email panel to draft the message:

• Select recipients (default is all results; you can uncheck specific rows)
• Enter a subject
• Choose the provided template (commonly named Aliyah Offer)

1. Send via:

• Email, or
• Hard copy letter (for mailing)

If the system warns that someone has no email address on file, you can:

• Contact them via phone, or
• Generate a hard copy letter for mailing

Offer email template behavior

The provided offer template is designed to auto-fill details from the honors record, such as:

• Honor name/description
• Service name and start time
• Date/time context (as stored for the honor)
• Prayer book page number(s)

Each message is personalized per recipient.

Recording Responses (Updating Statuses)

As congregants respond, update statuses directly from the honors query results:

1. Return to Queries → Honors.
2. Filter for Offered honors.
3. Use the Edit link on the relevant row.
4. Change the status:

• Offered → Accepted (or Accepted In-Person/Virtual)
• Offered → Declined

After updating, refresh the results. Items that are no longer “Offered” will drop out of the Offered list.

Honor History (Year-Based Tracking)

Honors are associated with a year, which enables historical lookback, such as:

• What honor a person had last year
• Trends across multiple years
• Reference when assigning future honors

This history becomes more valuable as you reuse and copy honors year-to-year.

Sending Reminder Communications to Accepted Honorees

As the holidays approach (e.g., about a week before), send reminders:

1. Go to Queries → Honors.
2. Filter by Accepted (and/or Accepted In-Person/Virtual).
3. Optionally filter by specific services.
4. Choose a reminder template (commonly named Aliyah Reminder).
5. Send emails (or generate hard copy letters as needed).

Reminder messages are also personalized and include the relevant honor and service details.

Managing Email Templates

Shalom Cloud provides starter templates (e.g., Aliyah Offer, Aliyah Reminder).

• Templates can be customized to match your synagogue’s language and branding (including logo).
• Templates include merge fields shown as phrases in curly braces {...}, which the system replaces with honor- and person-specific data when generating messages.

Recommended Operational Workflow

1. Upload honors spreadsheet (first year) or copy prior year (subsequent years).
2. Configure/confirm statuses (ensure Offered exists).
3. Assign honors and set initial status (usually Offered).
4. Run Offered query and send offer emails/letters.
5. Update statuses as responses come in.
6. Run Accepted query and send reminders.
7. Use year-based history for planning the next cycle.

See the full video: https://share.shalomcloud.com/jkuwPnl4?sa=technical_documentation

Recurring payments feel straightforward—until you run into the moment where “monthly amount” doesn’t behave the way you expected.

If you manage giving agreements or payment plans, there’s one distinction that quietly shapes how every installment is applied: Waterfall vs. Allocation. Both approaches are useful, but they produce very different outcomes—and one small mismatch can trigger a frustrating error.

What a Recurring Payment Plan Actually Does

A typical setup looks like this:

• A household agrees to pay a fixed amount on a repeating schedule (most often monthly)
• The system applies each payment to one or more items they owe (pledges, security fees, school tuition, etc.)
• The schedule can be monthly, but it can also be set to other intervals (more on that later)

The important part: how each payment is distributed depends on whether you’re using Waterfall or Allocation.

Waterfall Payments: “Start at the Top, Then Flow Down”

When no allocation amounts are entered, the plan uses waterfall logic by default.

That means:

• Each payment is applied to the first item in the list until that item is fully satisfied
• Only then does money begin applying to the next item
• Payments continue flowing “downhill” item by item

If you’re thinking, “So the ordering matters,” you’re exactly right.

How to change the Waterfall order

If you want a different item to be paid off sooner (for example, a security fee before a pledge), you simply reorder the items.

• Use the drag handle (often shown as a “hamburger” icon)
• Move the item higher or lower in the list

Whatever is at the top gets paid first.

Allocation Payments: “Split Each Payment Across Multiple Items”

Allocation is the alternative approach—and it’s used when you explicitly enter amounts for each category.

Instead of funneling 100% of each payment to the top item, you specify something like:

• X dollars per payment goes to donor pledges
• Y dollars per payment goes to security fees
• Z dollars per payment goes to school fees

This is ideal when you want every installment to contribute to multiple balances at once.

The Common “Sum of Allocations Does Not Match the Payment” Error

Here’s the wrinkle that catches people.

If the periodic payment amount doesn’t match the sum of the allocated amounts, the system will stop you from saving and show an error like:

• “Sum of allocations does not match the payment.”

This happens when:

• The recurring payment amount is lower than the combined allocations, or
• The allocations simply don’t add up to the recurring charge amount

How to fix it

You have only two valid paths:

1. Reduce one or more allocation amounts so the total equals the payment amount
2. Increase the periodic payment amount so it matches the sum of allocations

Once the numbers match, the update will succeed.

Switching Between Waterfall and Allocation (Without Rebuilding the Plan)

There’s a simple rule of thumb:

• To switch from Waterfall to Allocation: enter allocated amounts
• To switch from Allocation to Waterfall: clear the allocated amounts

This makes it easy to “flip” between strategies depending on what the payer wants.

It’s Not Just Monthly: Understanding “Periodic” Payments

While most recurring payments are monthly, the same capability supports other schedules.

Examples include:

• Every 3 months (quarterly)
• Every 6 months (semiannually)
• Every 12 months (annually)
• Even weekly intervals when needed

That’s why it’s more accurate to think in terms of periodic amount rather than “monthly amount.”

Quick Takeaways

• Waterfall applies payments top-to-bottom until each item is paid off
• Allocation splits each payment across multiple items, based on amounts you enter
• Allocation requires the sum of allocations to equal the periodic payment amount, or you’ll get an error
• You can switch between modes by adding or clearing allocated amounts
• Payment schedules can be monthly—or any supported interval

If recurring payments ever seem like they’re “misbehaving,” it’s usually not a bug—it’s that the plan is following one of these two rules exactly. Understanding which mode you’re in is the key to predicting (and controlling) where the money goes.

See the full video: https://share.shalomcloud.com/xQuXe7nZ?sa=blog_post

Saved queries just got more powerful.

About a week ago, we introduced Saved Queries across Yahrzeits—making it easy to store and rerun the same search criteria without rebuilding filters every time. If you missed that update, head over to this article for the full announcement and a walkthrough video.

Now we’ve expanded Saved Queries to one of the most time-sensitive areas of reporting: Financial Transactions.

What’s new: Save and reuse Financial Transaction queries

When you navigate to Queries → Financial Transactions, you’ll now see a dropdown that lets you select from any queries you’ve previously saved.

The first time you use it, the list will be empty—because you haven’t saved anything yet. But once you run a search you know you’ll need again, you can store it with a name and description for quick reuse.

Example: Save a fiscal year + fund + status search

Here’s a practical scenario:

• Go to Queries → Financial Transactions
• Build your query criteria (for example):
• Filter by Fiscal Year
• Select specific funds (e.g., Qantas Music Fund and Rabbis Tzedakah Fund)
• Set the transaction code/status to Paid
• Run the search to confirm you’re seeing the right results

Once you have the results you want, you’ll see new fields that allow you to:

• Enter a short query name
• Add a longer description (helpful when your team saves multiple similar searches)

Click Save Query, and you’ll get a confirmation that it’s been saved.

Run the same report again—without rebuilding it

When you come back later, simply:

• Return to Queries → Financial Transactions
• Open the Saved Queries dropdown
• Select your saved query

All of your criteria—such as the fiscal year, selected funds, and the paid transaction code—will be automatically restored.

Why this matters

Saved Queries for Financial Transactions help you:

• Save time on recurring financial lookups
• Reduce errors from re-entering filters manually
• Standardize reporting by reusing consistent criteria
• Move faster when you need answers quickly

If you rely on the same financial transaction views week after week, this update is designed to make your workflow smoother and your reporting more consistent.

See the full video: https://share.shalomcloud.com/lluLKr1e?sa=blog_post

Saved queries are here—starting with Yahrzeit Queries

If you regularly run the same searches—month after month, report after report—saved queries are designed to remove the repetitive setup work.

With this initial rollout, saved queries are available for Yahrzeit. More query types are planned for the future.

What is a saved query?

A saved query lets you store:

• The search criteria you entered
• The checkbox selections that control what shows up in your results

Instead of rebuilding the same search each time, you can select a saved query and instantly repopulate everything—then run the search.

How to save a Query

1. Run your Yahrzeit Query the way you normally would:

• Enter your criteria
• Select the checkboxes you want reflected on the results screen
• Click Search

1. You’ll now see an additional area that lets you save what you just configured.
2. Enter:

• A unique name (for example, “Standard Monthly”)
• An optional description to clarify the purpose

1. Click Save query

If something is wrong (most commonly: the name isn’t unique), you’ll see an error indicator so you can fix it and save successfully.

How to reuse a saved query later

After you’ve saved queries, they’ll appear in a dropdown the next time you return to Yahrzeit Queries.

When you select one:

• All previously-entered criteria are automatically filled in
• All checkbox selections are restored

From there, you can simply run the search—no rebuilding required.

Example: Create variations without starting from scratch

A common workflow is to start with a “standard” monthly query and then save a second version for a frequent subset.

For instance, you might run your usual monthly list, then add one more filter—like showing only Yahrzeits observed by active members—and save that as a second query (for example, “Yahrzeit Monthly – Active Only”).

This creates fast, repeatable options while keeping your reporting consistent.

A best-practice tip: keep your saved queries small and intentional

Saved queries are powerful, but they can lose their value if they multiply too quickly.

If you create too many (dozens of slightly different versions), it becomes harder to remember which one to use—and people often fall back to creating “just one more new query.”

A good rule of thumb: keep a minimum set of high-value saved queries that match your most repeated workflows.

Important: saved queries are shared (not personal)

Saved queries are common to your organization.

That means:

• If you save a query, others with administrative privileges will see it
• Saved queries persist even if the person who created them is away

This is especially helpful for consistency across staff—but it also reinforces why clear naming matters.

What’s coming next

Saved queries are currently limited to Yahrzeit Queries, but there are plans to expand this capability to other areas under the query menu, including:

• Financial transaction queries
• Members
• Households

Try it and share feedback

This rollout is intentionally focused so you can start using it immediately, evaluate what works well, and share what you’d like improved. Your feedback will help shape the next phases as saved queries expand into additional query types.

See the full video: https://share.shalomcloud.com/z8ujjmRG?sa=blog_post