Category: How to

New Audit Trail — Security Profiles

Audit trails are one of the most reliable ways to answer a simple question with confidence: what changed, who changed it, and exactly what was different before and after?

If you’ve used audit trails in the system before, you already know they’re invaluable for troubleshooting, compliance, and day-to-day accountability. Now that capability has been expanded to include something many organizations care deeply about:

  • Changes to permissions (also known as security profiles)

Below is a clear walkthrough of how audit trails work, how to read them, and what’s new.

How audit trails have worked for years

Under Maintenance, you can access Audit Trails and review changes across key record types (for example, site-related updates).

To run an audit trail:

  • Select the area you want to audit (such as changes to sites)
  • Choose a date range
  • Run the search

How to read an audit trail entry

Each audit trail result is designed to show you both context and precision.

You’ll typically see:

  • Date and time the change occurred
  • User who made the change
  • Record the change was made to (for example, a site, family, or financial transaction)
  • Action type (such as update or delete)
  • Versioning details (the system keeps prior versions)
  • Field-level changes showing the old and new values

That last part is where audit trails shine: you can see exactly what was modified within the record—such as a corrected spelling in a last name, capitalization adjustments, and even updates to key dates (including both Gregorian and Hebrew dates of death when applicable).

Not time-bound: historical changes remain available

A major strength of the audit trail is that it’s not limited to a short retention window. If a record was updated years ago and updated again recently, those changes can still appear—giving you a complete story of how the record evolved over time.

What’s new: audit trail for permission (security profile) changes

The newest expansion adds audit trail visibility into permission updates—in other words, changes to what users can do after they log in.

This means when a security profile is modified (for example, changing multiple permissions from No Access to Read Only, or adjusting a specific permission from Write to Read Only), those changes can now be audited.

To view permission-change auditing:

  • Open the Audit Trail on Permissions
  • Narrow the range to the timeframe you want to inspect (for example, starting from the current day)
  • Review the results to see a list of permission fields that changed and the before/after values

You’ll see each permission adjustment listed clearly—such as repeated transitions from No to Read Only across multiple entries, along with any other permission refinements made during the same period.

Why this matters

Permission changes are among the most sensitive updates in any system because they directly affect access and control. Having an audit trail for these updates supports:

  • Security reviews (confirming what access was granted or restricted)
  • Compliance and internal governance (proving when and how access changed)
  • Operational clarity (reducing confusion when a user reports different access than expected)

Takeaway

Audit trails have long provided detailed, versioned visibility into record changes. Now, that same transparency extends to security profiles and permission updates, giving you a clearer, more accountable view of access control changes across your organization.

See the full video: https://share.shalomcloud.com/7KuGqYb6

Customize Your Member Portal: Show and Hide Buttons

This change gives you more control over which buttons appear in the logged in member portal.

If you’re unfamiliar with the member portal, here is a series of articles about it. In brief, it gives your folks the ability to:

  • Update their own demographic information.
  • Pull a statement.
  • Make payments, both to amounts owed, and as contributions.
  • Set up recurring payments.
  • Search for other members of the congregation.
  • Link directly to your ShalomCloud shopping cart.

This specific change is rather narrow in scope, actually. It gives you finer control over which buttons you show on the member portal. You can

  • Show or hide the button to “Edit my family”
  • Show or hide the button to “See my statement”

Here is a video, showing how to make those changes, from the administrator’s perspective; and, then, what it looks like from the member’s perspective.

Convenience — Copy High Holiday Honors from a Prior Year

If you’ve used our Aliyot/Honors capability in a previous year, you can now copy those records into the current year.

If you’re unfamiliar with the ShalomCloud Aliyot capability, best to set up some time with us. We can go through the entire round trip, including:

  • Setting up the honors
  • Offering, or nominating, persons for each honor.
  • How to follow-up, either for those who have not responded.
  • How to send reminders for accepted honors.

In contrast, this announcement pertains to cases where you have a set of prior honors, and wish to get started on the new year.

It’s simply a matter of choosing a service (Erev Rosh Hashanah, Kol Nidre, et al.), using the “copy” link, and designating the date and time of the respective service.

Also — if you wish to copy the honorees from a prior year, there is a button for that, too. Or, if you want to start fresh, you can copy the honors themselves, but leave the honorees open.

Here’s a video that runs through this new process.

Copy high holiday honors

Now Available — Add/Change/Delete Purchase History

Until this change, the ShalomCloud shopping cart purchase history relied solely on purchases made online. You had no way to change those records. So, if someone accidentally signed up twice, or signed up and later informed you that they could not attend, you had no way to update that data. Your record counts would be off, and the funds collected (or to be collected), would be off.

Another situation: if someone wanted to make a purchase, or register for an event, but would prefer not to use the online shopping cart, you had no way to indicate that. Perhaps they mailed in a check for a Shabbat dinner, for example, and you wanted to add that reservation to the purchase history.

This change allows you to accommodate those situations. You can delete a purchase; and you can manually insert a purchase.

One major caveat, though — any financial ramifications would have to be handled separately, via the normal financial transaction screens.

Here’s a video that demonstrates some basic use cases.

Query for Deceased Members

You may or may not be aware that there is a flag to mark a member as deceased:

You can maintain this field under family maintenance; however, we recommend that you use more of an automated process, as described in this article.

But that’s not the point of this post. By default, the member query excludes deceased people. That’s in order to avoid the possibility of sending communications, either text or email, to those individuals.

In contrast, you may be interested in seeing information about those deceased persons. This change enables you to do that, by checking a box on the member query:

Note that, when you do choose to show deceased members, ShalomCloud automatically includes all billing statuses. That is a convenience, so that you needn’t worry about the default billing status of Active.

Announcing a new, more granular authorization

This post announces a new, more granular authorization — namely one specifically for handling items in the ShalomCloud shopping cart.

First of all, some background. If you’re not familiar with the ShalomCloud shopping cart, please review this handful of articles.

Some more background. ShalomCloud controls access to its major functions by means of a set of permissions, or authorizations. Each permission carries a flag — N for no access; R for read access; and W for read/write access. All well and good. In order to add or change items in the shopping cart, one needed the Financial permission. However, financial permission opens the door to see all financials, including pledges, contributions, and shopping cart activity.

And now we arrive at the focus of this article. You now have an authorization specifically for the shopping cart. In other words, you can grant access to create and update items in the shopping cart, without granting access to the rest of the financial information.

The accompanying video shows how you might set up such an authorization, and what that user can and cannot do.

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.

Easily Track High Holiday Honors

We’ve expanded on the already-available, but not widely publicized, ability for ShalomCloud to manage the process of assigning honors. This pertains primarily to the High Holidays, but could be used for any set of honors.

There a detailed tutorial available, which may serve better than this text description. Nonetheless, here goes. With this feature, you can

  • Nominate people to carry out various honors.
  • Track the status — accepted in person, accepted virtually, declined — whatever terminology you’re accustomed to using.
  • When assigning honors, ask for a specific last name, or by anyone who has not already been assigned an honor.
  • Obtain a spreadsheet, with contact information, of who has not received an honor.

And on the query side,

  • Obtain a list of honors for which there is no assigned person.
  • Ask for those who have been offered an honor, but who have not yet responded.
  • From that list, send formatted emails, with the specifics about the respective honor.
  • Obtain a list of those who have accepted an honor, and email a formatted reminder, replete with details about the honor.

How to gather and verify information about your members

We have two new small enhancements regarding the “Turnaround Document” — so-called because, when you send it to your congregation, they it turn it back in, with additions and corrections. We’ve had this capability for three years (https://blog.shalomcloud.com/2020/03/18/the-turnaround-document-2/), but it’s worth going over again.

First of all — if you’re not familiar with this term in ShalomCloud, perhaps it’s best to view the tutorial. That will cover what it is, what purpose it serves, and how to send it to your congregation. Basically, it’s a document that can either be sent via postal mail, one per family, or by email. It displays every piece of non-financial data in ShalomCloud on behalf of that family, with a place to write in additions and corrections.

The two new aspects of the turnaround document are:

  • Including the three emergency contact fields — a name, phone number, and email address.
  • A place to put a free-form message, after the individual members of the household, and before the Yahrzeits observed by anyone in the household.

Here’s a video that runs through the entire process.

Now has a free-form area, below members and above Yahrzeits