More control, more variety — choose your email template for statements

If you send monthly/quarterly statements by email, this may interest you.

Prior to now, you needed an email template, specifically named “send_statement_link.” Now, you’ll see a drop-down box, that lets you choose your email template for statements.

choose your email template for statements

This may be useful in a couple of circumstances, such as:

If you want to distinguish the statement email by monthly vs quarterly, or

If you send category-specific statements by email, and you want the content to be relevant to that category.


If you’re interested in some of the previous developments in regard to statements, feel free to peruse these articles:

The directory and the portal — respecting privacy

If any of your folks have expressed a desire to NOT appear in your ShalomCloud membership directory — – or, if they wish to not appear in the member portal search — here is how you’d fulfill that wish.

First, create a family attribute, specifically with the abbreviation _EXCL. That’s uppercase EXCL, preceded by an underscore.

Then, you’d proceed to tag the privacy-oriented families, using Maintenance -> Assign Family Attr.

Once so tagged, when you produce a directory (Queries -> Produce Directory), that entire household does not appear.

Also, in the member search section of the logged-in member portal, people in the excluded families do not appear.

Video illustration.

New warning on duplicate form responses

With the ShalomCloud form builder, you can declare certain questions as auto-bill. This means that, depending on what the user selects, ShalomCloud creates an amount owed. Example — membership type, like this:

  • Family membership $2000
  • Single membership $1000
  • Senior couple $1200

What has been happening on occasion, is that either both adults in a household respond to the form — or the same person responds a second time. The result would be double-billing. Two family memberships, in the above example, for a total of $4000.

Now, with this safety check, when someone accesses a form, the system checks whether anybody in the household has already submitted the form. The system provides the name of that person, and the date of the previous form submission.

One caveat — this is just a warning. That is, it does allow the 2nd person to continue with the form. Why? At this juncture, we are leery of stopping those cases where, perhaps, someone didn’t fill out the form completely, and just wants a do-over. Depending on how this plays out, we can consider preventing the subsequent submission.

Also — we have not yet applied this logic to school registrations. Most assuredly, it needs to be there, but we opted to put this portion of the enhancement into production.

Here’s an end-to-end run-through of the first, then the duplicate, form submission.

Two Small Enhancements — Plaque Location on the Bimah list…

and a summarized version of the Deposit Assistant.

We have two small, unrelated enhancements to show you.

Enhancement One: This relates to the combination Bimah list. The combination Bimah list, for those of you not familiar with it, combines onto one list, the Yahrzeits observed by Hebrew date, along with those observed by Gregorian date.

The combo Bimah list contains a growing numbers of options. Prior to now, those options were

  • Group by month, or group by day.
  • Whether or not to show the relationships on the list (e.g. father of, mother of).
  • To include all Yahrzeits with plaques, whether or not there was an observer.
  • Whether to specifically exclude relationships with a notification flag of “N” (meaning do not notify).

Now, we have one additional checkbox. If you’d like to show the plaque locations on the Bimah list, there is a corresponding selection.

For our second small enhancement, we turn to the Deposit Assistant. Here, as before, you can select recent incoming funds, either by Deposit ID, or by date range. Until now, the report always showed the detailed line items, grouped by category, within the source — cash, check card, ACH, etc.

Now, you’ll see an additional radio button — to produce the report in summary, with only headings and totals.

Here’s a video that runs through these two features.

Name-only Labels

ShalomCloud has for years been able to print labels. That is true both for individuals and for family units. However, until now, the labels were strictly mailing labels. That is, the program always printed the mailing address onto the label.

With this change, you now have the choice of printing name-only labels — excluding addresses. For family units, that name can be the formal name (“President George Washington and Mrs. Martha Washington”), or the informal name (“George and Martha”), or the informal label (“George and Martha Washington”). For individuals, it’s the title, the first name, and the last name.

A few possible uses for name-only labels: seating for a community Seder; badges for social events; badges for religious school, to name a few.

Here’s a short video showing the two places from which you can produce name-only labels.

Name-only labels
Labels — choice to include names only

Specific Item in the Shopping Cart

You now have the ability to point a link or button to a specific item in the shopping cart.

ShalomCloud has offered a shopping cart for some time now. That enables simple event registration, and the purchase of fixed-priced items. That could be classes, high holiday tickets, Hamantaschen, Siddurim–really anything with a price, including zero.

However, we’ve received feedback about the desire to point to a specific item in the cart, instead of showing all available items. That’s what this change provides.

Here’s how it works — when you’re configuring your items in the cart, you’ll see here and there a “Show” link. By selecting that link, you’ll see a new field, labeled Direct link. By using a button or link — on your web site, or in an email blast, for example–and directing people to that direct link, only that one item will show in the shopping cart.

This video shows how it works.

Specific item
Cart specific item — annual concert

One-time Password

For an extra layer of security, you may now take advantage of our one-time password capability.

One-time password? What’s that? Until now, logging into ShalomCloud was a matter of entering an email address and a password. That is still the default.

However, if you enter the synagogue options panel, you’ll see three choices: To not use OTP, or to require OTP for all, or to have OTP be an individual option.

If you opt to require OTP, everyone logging into ShalomCloud will see a second login screen. At the same time, the system will send that user a numeric code, to the logon email; and, if there is a cell phone in the user’s profile, the system will also send the code via text message.

If you make the second factor an option for your synagogue, then you’ll use a checkbox for each individual who prefers to log on via both email/password, and the six-digit number sent via email and/or cell.

Please follow this video to see how to put this capability into action.

One-time password
Process Flags

Some possible future enhancements:

Offering a preference between cell phone and email, to receive the code. For now, since cell phone is a new field in the user record, we’ll send to the email always, and the cell phone if it’s there.

Offering authentication via a phone app, such as Google Authenticator or Twilio Authy. This would mean scanning a bar code with your phone, and then using the phone app to retrieve the login code. This is considered a more secure way to implement MFA (Multi-Factor Authentication), but more complex.

Small Enhancements

Here are described several small enhancements. Most of the time, we include a video. However, in this case, a screen snapshot should serve well to illustrate these changes.

When you’re doing Yahrzeit maintenance, you will now see a search box to jump right to the last name in question. This saves you from scrolling through several pages of Yahrzeits.

Yahrzeit search
Yahrzeit search

Second of the small enhancements: in the area of financial categories. If you use our contribution portal, you’re probably aware that you can select which categories appear in the drop-down box. You’d select “public” for those; the rest are internal, or private. If you have dozens to hundreds of categories, but want only a handful to appear in the portal, you can use the new button to declare all categories non-public. After using that button, you would flip to public the relatively small number of categories to appear in the portal.

Make all non-public

Third thing — if you use our form builder, and specifically radio buttons and check-boxes — you now have up to sixteen choices for each, up from five.

While we’re on the subject of the form builder — if you’d like to see responses from prior forms, you can now select which set of forms or registrations you’d like to review:

Select a registration

Display Children in the Directory

This article announces a change in how to display children in the directory.

First, some background — please read this previous article on a few changes that preceded this one.

Now, for this change. Until now, if you wanted to list children in the directory, you would select their roles, along with adults and parents. With that choice, children would appear if they had a cell phone or email. If they had neither, their names would not appear. Moreover, if you wanted to show children’s names, but omit the cell and email, you would have to individually check that option per child.

It’s simpler now. Basically, you can follow two rules. Rule one — the Role within family determines whose names appear with their personal contact information. Rule two — by adding the phrase {children} to the letter template for the Directory, you’ll display children in the directory. First names only, as a list.

Here’s a short (3m, 36s) video showing this change in action.

How to add a list of children within the directory.

Notification Flags

Now available — email notification flags, to control who receives any of various notifcations.

Until this change, the system used three rules to determine who received email notifications:

  1. Anyone with read or write permission for financial activity would receive an email whenever a payment occurred.
  2. Anyone with read or write permission for schools would receive an email whenever a school registration occurred.
  3. Anyone with read or write permission on families would receive a notification whenever any other type of form arrived.

With this change, you can designate which of these notifications go to each user. You’ll see a yes/no choice, when you edit the profile for any user.

Be it noted that, initially, we’ve set the flags such that there is no change in who receives what. Thus, we recommend that you have a look at your profiles, and turn off the flags for those who are receiving extraneous email notifications.

Feel free to look over this short (2m, 50s) video showing how to edit these three new flags.