You manage group requirements under Admin Tools > Settings > General > Group Requirement Types. Editing a requirement allows you to provide the following configuration options. Name - This is the name of the requirement. This will appear on the Detail screen in the internal site, and within the fundraising groups pages externally.Description - Be sure to provide a good description of the requirements and any of the underlying criteria that are used to determine whether a group member meets the requirement. A little documentation now will save you headaches in the future.Icon CSS Class - You can optionally associate an icon with the requirement. The icon will appear in places like the group member detail screen, or as a requirement for fundraising groups (e.g., for trips).Category - It can be very helpful to categorize your requirement types, especially as your list starts to grow. To add categories for requirement types, navigate to Admin Tools > Settings > System > Category Manager and create a new category with an entity type of Group Requirement Type.Summary - The Summary you provide will be shown in places where the requirement is displayed, such as the group member detail screen.Check Type - So how do we determine the logic of whether someone meets a requirement? Rock gives you three options:SQL: In this case you provide a SQL statement. This statement should return a list of Person Ids in the database that meet that requirement.Data View: You can also select a data view that returns a list of all the people who meet the requirement.Manual: This requires someone to manually determine if a person meets the requirement. Descriptive Labels - People will either meet the requirement, be in a warning state or not meet the requirement. According to the group member's state, these labels will appear where the requirement is displayed, such as the group member detail screen and as a requirement for fundraising groups.Requirement Workflows - You can launch workflows for people who either do not meet the requirement or who are in a warning state. Based on the Auto Initiate setting described next, the workflow will be launched either manually or automatically. The entity passed to the workflows will be a Group Member Requirement entity. If your workflow has a Person attribute with a key of "Person", the corresponding person will automatically be set in your workflow. Requirement workflows must be automatically persisted.Auto Initiate - You can choose to automatically launch a workflow at the point when Rock first determines that the group member does not meet a group requirement or that they're in a warning state. If this is disabled, then the workflow can be manually launched in places where the requirement is displayed.Link Text - If the workflow is going to be launched manually based on the Auto Initiate setting, this is what the link to launch the workflow will say. If nothing is provided here, then default text (e.g., "Requirement Not Met") will be used.Can Expire - Some requirements, once met, will always be true - say for instance a requirement that you take a specific class before serving. Other requirements may expire. A good example of this is a background check or CPR certification. It's important to keep in mind that the Calculate Group Requirements job will not automatically re-check to see if the person still meets the requirements unless Can Expire is enabled.Expire Duration - When a requirement can expire, you can set the number of days in the future to wait before re-checking the requirement. For something like a background check, you don't need to look every day to see if the background check is still valid.Due Date - Each requirement of this type will have a due date, and this is where you indicate how that due date is determined.Immediate: The requirement applies as soon as the person is added to the group.Configured Date: When adding this requirement type to groups or group types, you'll be able to choose a date on which the requirement is due.Group Attribute: You'll use this option if you have a group attribute that contains the date on which the requirement is due. You'll choose the attribute when the requirement type is applied.Days After Joining: This option gives everyone the same amount of time after joining to complete the requirement. Save - Don't forget to save! As noted above, the Expire Duration is how many days Rock will wait before checking requirements again. With background checks it typically isn't necessary to re-check every day, or even every week or month. But there are edge cases to consider. For instance, let's say someone passed a background check yesterday and, as a result, shows up as meeting the group requirement. Then today something changes with the requirement (e.g., the Data View is updated) and the person no longer meets the requirement. The Calculate Group Requirements job will not re-check this person's requirement until after the Expire Duration has passed. In such cases the person will appear as meeting the current requirement, even though they don't. If someone does not meet a requirement and the due date has not been reached, then the person is considered to be in a warning state. TipTips for Creating Data Views and SQL ExpressionsWhen creating data views and/or SQL expressions for group requirements keep these two things in mind:- Meets The data view/SQL expression for meets should return a list of all the people in the database that meet this requirement.- Warning This data view/SQL expression should return a list of all the individuals in the database in a warning state. When you apply a requirement type to a group or group type (see the following sections below for instructions on that) you have the option of allowing group leaders to override the requirement for individual group members. For other staff or volunteers, you can indicate who can override requirements by accessing the security for the requirement type by clicking the ti ti-lock icon and adjusting permissions for Override.