S
Seth Meldon
Guest
In this walkthrough, we’ll show you how to implement rules that provide salespeople with specific content depending on the context of the application they’re working in, permissions for their role and sales process workflow rules.
There are three categories of rules:
Category 1: File type rules
1. Only files with type .ppt or .pptx should be visible within the Presentations app
2. Only files tagged with “Product1” appear in the Teams app
3. Only files modified within the last week appear in recently accessed items
Category 2: Role permissions rules
1. Director level employees with role of analyst has permission to use the ad hoc reporting tool
2. Within Tenant A, users in Group B can only download assets on mobile devices
3. Within Tenant B, users in Group C can only see opportunities in the West District in the CRM
Category 3: Workflow rules
1. Every week, push reports A and B to all manager level roles in Tenant D except for those in the West Region
2. If an opportunity’s data quality index (dqi) drops below 20%, email Sales VPs a warning
3. If a question that appears in multiple RFPs is updated, retroactively update all prior RFPs the question appears in
1. Only files with type .ppt or .pptx should be visible within the Presentations app
2. Only files tagged with “Product1” appear in the Teams app
3. Only files modified within the last week appear in recently accessed items
Optimizing Rulesheet Logic: Ambiguity (Conflicts) Checker
The conflict checker shows that as currently modeled, the rule action only allows us to choose ONE application to grant access to. At this point we need to revisit the rules and ask, “What is the actual intent of these rules?”
Does rule 1 mean:
Depending on how we want the rule to behave we may need to change the rulesheet. Let’s assume the intent of the rules is to permit access to all Applications for which the file meets the specified rules. This means we cannot have a single attribute for the result because a subsequent rule will override a prior rule’s result.
To correctly model this we need to introduce a new business object (the
The rule sheet then needs to be changed as shown below. Within the scope section, we’ll define an alias, “app”.
When the conditions are met, a new instance of
Now, we can test specific scenarios against the rules to validate the behavior:
1. Director level employees with role of analyst has permission to use the ad hoc reporting tool
2. Within Tenant A, users in Group B can only download assets on mobile devices
3. Within Tenant B, users in Group C can only see opportunities in the West District in the CRM
Group 2 is a little more complex since we need to model the relationships between a user and:
a. The
b. The
c. The
In this model we assume that a user may have many
Their permission levels are now defined in a new rulesheet:
1. Every week, push reports A and B to all manager level roles in Tenant D except for those in the West Region
2. If an opportunity’s data quality index (dqi) drops below 20%, email Sales VPs a warning
3. If a question that appears in multiple RFPs is updated, retroactively update all prior RFPs the question appears in
Group 3 could be split into three non-overlapping parts, but for now we’ll keep them together in this vocabulary:
Since these three rules are unrelated to each other (except that they have something to do with Workflow), it makes the most sense to model them in separate rulesheets. In fact, if we put them all on a single sheet you can see how they are independent since none of the rules share any of the attributes:
Let’s instead split them into three sheets with their own respective test cases.
1. Every week push reports A and B to all manager level role people in Tenant D except for the West Region.
2. If an opportunity’s data quality index (dqi) drops below 20%, email Sales VPs a warning.
3. If a question that appears in multiple RFPs is updated, retroactively update all prior RFPs the question appears in.
This is just a taste of the complexity of rules that can be codelessly authored and operationalized in Corticon. To learn more or try a free evaluation, visit progress.com/corticon.
Learn More
Continue reading...
There are three categories of rules:
Category 1: File type rules
1. Only files with type .ppt or .pptx should be visible within the Presentations app
2. Only files tagged with “Product1” appear in the Teams app
3. Only files modified within the last week appear in recently accessed items
Category 2: Role permissions rules
1. Director level employees with role of analyst has permission to use the ad hoc reporting tool
2. Within Tenant A, users in Group B can only download assets on mobile devices
3. Within Tenant B, users in Group C can only see opportunities in the West District in the CRM
Category 3: Workflow rules
1. Every week, push reports A and B to all manager level roles in Tenant D except for those in the West Region
2. If an opportunity’s data quality index (dqi) drops below 20%, email Sales VPs a warning
3. If a question that appears in multiple RFPs is updated, retroactively update all prior RFPs the question appears in
Modeling the Group 1 (Content) Rules
1. Only files with type .ppt or .pptx should be visible within the Presentations app
2. Only files tagged with “Product1” appear in the Teams app
3. Only files modified within the last week appear in recently accessed items
Vocabulary
Rulesheet
Optimizing Rulesheet Logic: Ambiguity (Conflicts) Checker
The conflict checker shows that as currently modeled, the rule action only allows us to choose ONE application to grant access to. At this point we need to revisit the rules and ask, “What is the actual intent of these rules?”
Does rule 1 mean:
- ppt and pptx can ONLY be accessed by Presentation?
- Only Presentation can access ppt and pptx?
- Presentation can ONLY access ppt and pptx?
- Allow all accesses if the file happens to be ppt and Product1 and SPP?
Depending on how we want the rule to behave we may need to change the rulesheet. Let’s assume the intent of the rules is to permit access to all Applications for which the file meets the specified rules. This means we cannot have a single attribute for the result because a subsequent rule will override a prior rule’s result.
To correctly model this we need to introduce a new business object (the
Application) and set up a relationship between the files and the applications that are allowed to access them. This will be a many-to-many relationship:
The rule sheet then needs to be changed as shown below. Within the scope section, we’ll define an alias, “app”.
When the conditions are met, a new instance of
Application (given the alias within this rulesheet, "app") will be created as a child entity of File.
Testing the Rulesheet
Now, we can test specific scenarios against the rules to validate the behavior:
Modeling the Group 2 (Permissions) Rules
1. Director level employees with role of analyst has permission to use the ad hoc reporting tool
2. Within Tenant A, users in Group B can only download assets on mobile devices
3. Within Tenant B, users in Group C can only see opportunities in the West District in the CRM
Group 2 is a little more complex since we need to model the relationships between a user and:
a. The
Groups in which they belongb. The
Roles’ respective permissionsc. The
Tenants to which they’re assignedVocabulary
In this model we assume that a user may have many
roles, tenants and groups:
Their permission levels are now defined in a new rulesheet:
Modeling the Group 3 (Workflow) Rules
1. Every week, push reports A and B to all manager level roles in Tenant D except for those in the West Region
2. If an opportunity’s data quality index (dqi) drops below 20%, email Sales VPs a warning
3. If a question that appears in multiple RFPs is updated, retroactively update all prior RFPs the question appears in
Group 3 could be split into three non-overlapping parts, but for now we’ll keep them together in this vocabulary:
Rulesheets
Since these three rules are unrelated to each other (except that they have something to do with Workflow), it makes the most sense to model them in separate rulesheets. In fact, if we put them all on a single sheet you can see how they are independent since none of the rules share any of the attributes:
Let’s instead split them into three sheets with their own respective test cases.
1. Every week push reports A and B to all manager level role people in Tenant D except for the West Region.
2. If an opportunity’s data quality index (dqi) drops below 20%, email Sales VPs a warning.
3. If a question that appears in multiple RFPs is updated, retroactively update all prior RFPs the question appears in.
This is just a taste of the complexity of rules that can be codelessly authored and operationalized in Corticon. To learn more or try a free evaluation, visit progress.com/corticon.
Learn More
Continue reading...