A Page View is a filtered list of records on a page. For example, a Page View titled "Birthday Next Month" on the Contacts page lists any active Contacts with Birthdays in the next calendar month.
Page Views are a saved as query which 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 is prepended by an In / Not In 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.
A Personal View has a User specified. They are visible to the User and may also be shared with a User Group.
A Shared View has a User Group specified. They are visible to everyone in the User Group or a User (if 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 opening the Notification dialog and clicking the name link:
A System View does not have User or User Group specified. They are visible to everyone. All Views can be managed by SPoCs in the System Setup > Page Views.
- 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 via the Setup Layout tab or System Setup > Page Views.
- A Page View can show a field (column) from a directly, or indirectly, related record up to 6 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.
- 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?
- They should load in under 30 seconds, but 3-4 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 cannot 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 return the first child record, or using advanced SQL (the STUFF function) to create a list in a single field.