Category: General

New Selection on Statements

There is now a new selection on statements, namely a “not” attribute.

In our quest to continually provide you with more flexibility, we’ve rolled out quite a few more options for producing periodic statements, over the years. To summarize here, those options have included:

  • Choose your email template when sending statements.
  • Include or suppress payment details.
  • Include or exclude credit balances.
  • Select a subset of categories (e.g., school-only).
  • Include or exclude a recent-payments section.
  • Select statement recipients by family/household attributes.

This is yet another of those incremental improvements. In regard to those attributes — you can now select by households that do NOT have a certain attribute.

Couple of examples where this might prove useful.

  • Your standard is to produce statements by email. However, you have some families who expressly want a paper statement only. In that case, you might set up an attribute, “Surface mail only.” Then, when your embark on your standard statement run, you can select Does not have attribute Surface mail only.
  • Your standard practice is to run statements monthly. In contrast, a few families want this communication quarterly. Accordingly, you’d set up an attribute, such as “Quarterly.” Then in your monthly run, select Does not have attribute Quarterly.

Here’s a video depicting this idea in motion.

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.

In the drop-down box — instead of showing all your email templates, the program will show only your email templates that contain the word “statement“. Doesn’t have to start with statement. So, “Monthly Statement,” or “Religious School Statement,” or “Membership Statement” will all appear in that drop-down box.

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

Choosing specific categories

Suppress detail on statements

Including a link in the email, that will log the person into the member portal.

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.