Views
A Page View is a filtered list of records on a page. For example, this view on the Groups page shows all Current Small Groups.
Page Views are a saved query that is run against all records when it is selected from the View list or refreshed using the Refresh button. This means Views are dynamic, as opposed to Selections, which are a static list of records.
In/Not In View
The Views drop-down list is preceded by an In/Not In drop-down button. Toggling this setting will reverse the result set. When reversed, each filter clause is reversed to create the "Not In" View. For example, if a View displays everyone with an email address who is over 18, the reverse will show everyone who does not have an email address and is under 18.
Personal Views
A Personal View has a User specified. They are visible to the User and may also be shared with a User Group.
Personal Views can be created using the Advanced Search Tool or by a SPoC under .
Shared Views
User Groups
A Shared View has a User Group specified. They are visible to everyone in the User Group or a User (if it's a Personal View). User Groups can only be assigned to Page Views, not Sub-Page Views.
Direct Links to Views
The easiest way to get a link to the View is by selecting the view you'd like to share and copying its URL. Paste that URL into an email or message and share away!
System Views
A System View does not have User or User Group specified. They are visible to everyone. All Views can be managed by SPoCs under .
Features
- Page Views facilitate searching, sorting and selecting.
- Page Views can be exported.
- The order of and columns (fields) listed in a Page View can be defined.
- Complex criteria can be written with SQL and added through the Setup Layout tab or .
- A Page View can show a field (column) from a directly, or indirectly, related record up to six tables removed. For example, you can add the postal code of a donor from a page view on the Donation Distributions page.
- A Page View can also contain summary values. For example, the total of all donations this year can be viewed on the Donors page, but this is not the primary purpose of page views.
Uses
- Hiding records that are not relevant to the task at hand. For example, a view showing all active widows and their assigned deacon would be useful to a Deacon's ministry.
- Displaying records that need immediate action. For example, show all widows added to our system this month who haven't been followed-up with by our Widow's ministry.
- Providing columns needed for ad-hoc searching. For example, how many active widows do we have over 59 years of age? If age is a column listed, searches within that view for that criteria are allowed.
- Providing a quick count of records meeting a specific set of criteria. For example, how many active widows do we have in our church?
- Finding data that needs to be fixed/updated. For example, how many active widows do we have without a deacon assigned?
Limitations
- They should load in under 30 seconds, but three to four is best. It is possible to conceive a view that takes too long to load. A report is needed in these cases.
- A Page View can't list child record data. Only one row per record is allowed in a Page View, so listing information for a child record is not allowed as each record can have more than one child record. In cases where this is needed, create your page view on the child-record page itself. For example, if you want a view showing everyone who checked in last Sunday, you make that view on the Event Participants page not on the Events page:
- There are workarounds for this limitation, such as returning the first child record, or using advanced SQL (the STUFF function) to create a list in a single field.