Rule Set Cookbook: A Collection of Examples

This document provides a collection of examples for creating rule sets.

Note: The rules shown here may be simplified for readability. They are well-suited for direct use as simple ad-hoc reports or filters. If you intend to use them for sending notifications, please review our guide on preventing email storms to avoid unintended consequences.

Find All Users Restored in the Last 14 Days

This rule set identifies all users who have been restored from a deleted state within the last 14 days.

It functions by checking that the user is not currently deleted and then searches the user's history for a "Recover" entry registered within the last 14 days.

• [OBJECTHISTORIES; EntryType; EntryType; Recover]: This checks the user's history for an entry of the type "Recover".

• [OBJECTHISTORIES; Registered; EntryType; Recover]: This retrieves the registration date for the "Recover" entry.

Find Users with Permissions Expiring in 10 Days

By default, we recommend a one-year duration for manually granted access. This rule set is useful for notifying relevant parties when this access is about to expire.

This rule can be used in a notification template to send an alert when a permission is 10 days away from its expiration date.

Note: In the rule [OBJECTPERMISSION; Expiry Date;SystemId;72], replace "72" with the ID of the specific permission group you want to monitor. The rule will be triggered for any permission within the specified group that is approaching its expiration date.

Find Employees with an End Date in the Next 14 Days

Identifying an employee's end date can be complex, as it depends on company practices and the employee's contract type.

• Permanent employees typically have their end date recorded in the "End Date" field of their employment record.

• Temporary employees often have an end date set on their position, either in the "Last Payroll Date" or "Position End Date" field.

To ensure all cases are covered, the rule set must check all possible fields using the following logic:

• Is the employment end date between today and the next 14 days?

• Are all position end dates before 14 days from now, AND is at least one position end date after today?

• Is the last payroll date for all positions before 14 days from now, AND is at least one position end date after today?

Warning: When using this rule set in notification workflows, it is critical to include a [COUNTMESSAGESENT;] check for each Or operator to prevent sending duplicate messages.

Find All Employees in a Department and its Sub-departments

This rule set retrieves all users who have a position associated with a specific department, including all sub-departments beneath it in the organizational hierarchy. This can be generated automatically using the rule set wizard.

Find All Employees with a Permission Tied to a Deleted Department

This rule returns a list of usernames, permission names, the associated department name, and the date the department was deleted.

[FOREACH; ObjectPermission; ManagerOf#[REPLACE; [SELECTION; 51274; Id); ;, ; ObjectId, Object.Display

Warning: If this is used in a notification workflow, ensure the message rule is configured to trigger on only one user and includes a [COUNTMESSAGESENT] condition to prevent unintended behavior.

Find All Users Created in the Last 14 Days

This rule set identifies all user accounts created within the last 14 days.

Find All Employees in a Department, Including the Manager

Often, a department manager's organizational affiliation is at a level above the department they manage. To create a rule set that includes both the employees in a department and its manager, use the ManagerOf attribute.

The first rule identifies all employees in the specified departments. The second rule adds the managers of those departments to the selection.

Note: The ManagerOf attribute refers to the department's internal ID number, whereas the DepartmentNumber for an employee refers to the more commonly known unit number. This can be complex. Here are two ways to handle this:

1. Find the Internal ID from the Rule Builder:

   • Select the Manager Of attribute.

   • Choose the Is one of condition.

   • Click Select a value from an object to look up and select the relevant departments.

2. Use the [REFERENCE] Function:

   • Look up the internal ID based on a known unit number with the following syntax:

   • [REFERENCE; SourceId; OrgUnitnr;3; 2000|2202]

Find All Department Managers

This rule set finds all users who are designated as department managers in the organization. The ManagerOf attribute contains a value if the user is a manager.

Find All Employees Who Are Not Managers

This rule set finds all active employees who do not have a manager role.

Alternative: Invert an Existing Rule Set

Since you already have a rule set for "All Department Managers," you can reuse it to find everyone who is not a manager.

Find All Employees with a 0% Position

This rule set finds all employees whose primary position has a position percentage of 0.

Alternative: Check All Positions

This rule finds users where none of their assigned positions have a percentage other than 0.

Find All Elected Officials Without Other Municipal Positions

This rule set finds everyone whose primary position type is "Elected Official" and who does not hold another position in the municipality. The final line excludes the mayor from the results.

Note: The values for position types may vary between different municipalities.

Event-Based Rules (Triggers)

Trigger When an Employee Changes Primary Position

This rule set triggers when an existing user's Department Number attribute is changed.

• Line 1 (Entry Type = Edit): Triggers only when an existing user is modified.

• Line 2 (AttributeName = Department Number): Triggers only if the change involves the department number.

• Line 3 ([LASTVALUE; ...] is not equal to [DepartmentNumber]): Ensures the rule doesn't trigger if a department's name or number is updated without an actual change in the user's assignment.

• Line 4 ([LASTVALUE; ...] has value): Ensures the user was assigned to a department previously.

Trigger for New Users Without a Registered Mobile Number

This rule triggers when a new user is created without a value in the Mobile field. It can be used to notify a manager or HR that information is missing.

Trigger on Changes to Users with a Specific Permission

This rule triggers when specified attributes are changed for any user who holds a particular role in an access management system. It can be used to notify a system administrator of changes affecting users with specific access rights.

• Line 1 (Entry Type = Edit): Identifies the event type as an edit.

• Line 2 (AttributeName Is one of...): Specifies which attribute changes will trigger the rule.

• Line 3 ([OBJECTPERMISSION.SYSTEMROLE; ...]): Identifies the specific permission (ID 8735, Name Tidbank) the user must have for the rule to trigger.

License Management Rules

Find Users with More Than One License in the Same Group

This rule is typically used to identify employees who have been assigned multiple licenses for the same product (e.g., Microsoft 365), whether assigned manually or automatically.

Note: The first line counts the number of permissions a user has in group 2927. You must change this ID to match the license group you want to check. The condition "is greater than 2" should be read as "has 2 or more permissions." The second line filters for active users only.