Approval and Permission Engine
1 General Introduction
This system administration guide contains key information to setup Manufacturing Sales Platform (MSP) Approval and Permission Engine effectively. The guide provides the concepts and detailed definition of the functions, aiming to enable administrator to have sufficient knowledge to setup the function with minimal supervision.
The document will be continually edited and updated based on latest product releases. Taking into the consideration of expensive effort keeping the document updated and effective usage of it, only major and complex features should be covered.
To better illustrate how to setup certain feature, some examples are given. It also contains the steps linked to relevant screens. Each step contains actions which the administrator needs to perform to complete the setup. This administration guide is based on Sales Platform release version 1902.
The Product Engineering Team
2 How to setup approval workflow
2.1 Approval and Permission Engine Introduction
ISS/CPQ supports approval of quotation and workflow based on the rule. It offers defining and maintenance of the rule conditions and rules from the system. To achieve this certain concept, the following business types are introduced here:
- Approval Rule
- Condition Type
- Rule Status
- Approval Gate Flow
3 Concept of Approval
3.1 Approval Rule
Approval value is the fundamental part of Approval Engine. It is composed of one or more conditions and one mandatory approval gate. It also has its own status active or not.
- Rule Status
Available rule statuses are RULE_ACTIVE and RULE_INACTIVE. If rule status is inactive, approval rule is not run and will be consider is logically deleted.
Each approval rule consists of multiple conditions. Rule is fired only when all the conditions are satisfied.
- Approval Gate Flow:
“HasApprovalGateFlow” is the outcome of the rule. When the rule is fired, it is the starting point of whole workflow process. Depending on who submit the quote, ISS will recursively find the approval gate with higher role according to role hierarchy.
Condition is the most basic and atomic unit of approval rule and looks like to an equation. A condition can be used by more than one approval rules to increase reusability.
3.3 Condition Equation
|2||Business Type||Business Type of condition to be applied. (Left side the condition)|
|3||Attribute||Attribute of condition to be applied. (Left side of the condition)|
|4||Search Expression||Search expression. (left side of the condition)|
|5||Operator||Operator of the condition.|
|6||Condition Value||Value of the condition. (Right side of the condition)|
|7||Secondary Condition Value (Applicable only for price item type attribute)||If administrator chooses attribute as price item type, secondary condition value is appeared in UI to make further filter.|
|8||Check on Price Item Base Amount (Applicable only for price item type attribute)||By default, if the value is not set, the condition is applied on target amount. If user want to check on the base amount, the flag must be on.|
|9||Condition Source (Applicable only for price item type attribute)||Applicable values are: 0 for Default (No filtering) 1 for ERP 2 for User Justified 3 for SSC only 4 for both ERP and User Justified.|
Scenario for usage of Item 7, 8 and 9: Administrator wants to define a condition that price item type is “Added Fee” and the base amount value is greater than 30. Since we have different pricing (SSC, ERP), there are several options to make further filter. When administrator choose price item type, UI will automatically show (7) Secondary condition value, (8) Check on Price Item Base Amount (9) Condition Source. Quote that you should know – “If quote is satisfied all the conditions of the rule, it is assumed that the rule is fired. If one of the Sales Items is satisfied all the conditions of the rule, it is assumed that the rule is fired.” 1.Attribute Condition attribute can be any business data attribute and business relation attribute on quote, SaleItem, DocumentHeaderPriceItem, and ItemHeaderPriceItem. During approval rule firing, the actual value of this attribute is substituted as left operand. Search 2.Business Type The domain of condition attribute it belongs to. Currently the two business types supported are Quote and SalesItem. The condition business type needs to be used either Quote or Sales Item depending on attributes are on Quote level or Sales Item level. 3.Search Expression Search expression is useful if condition wants to use attribute that is not shown in the condition attribute. It provides facility to retrieve data more than the defined types such as, 4.Condition Value The value that is used to check in the condition as right operand. User can input any value regardless of the type. Moreover, ISS supports a predefined set of constant values via ConditionEnvironmentVariables. The followings are individuals of condition environment variables:
Represent current login user business object.
Represent current login user role business object.
Represent today date. For example, these constant values can be used in conditions such as quote creator must be current logged in user or current logged in user role. 1.Operator Operator in CPQ is similar concept to operator in mathematical equation. Eight types of operator are supported as follows:
- equal to
- greater then
- greater than or equal to
- less than
- less than or equal to
- not in
Among these operators, depending on the range of condition Attribute, ISS/CPQ supports the operators as shown in matrix: Things to Note About
- In operator is checked for the value IS contained among the given possible values.
- NOTIN operator is checked for the valued IS NOT contained among the possible values.
- >, >=, < and <= operators can be used for only decimal and integer.
1.Special Condition Two type of special conditions are providing:
- System Condition
System condition is a condition that is applicable to all rules. Common conditions could be defined as system condition.
- TRUE Condition
True condition is a condition whose result is always true. For example: It can be used in a situation where modeler needs to make a rule true by default.
3.3.1 Approval Gate
Approval gate has user role who is responsible for current workflow step and next stage (approval gate) if existed.
3.4 Setup steps and UI interaction of Approval
When the quote is in OPEN status, any user can check dynamically what will be the approval flow and who will be the approvers based on the existing quote data and current login user perspective without submitting the quote.
|Range of Condition Attribute||Decimal||Integer||Boolean||String||Calendar||Business Relation Attribute|
Anybody who can update the quote can also submit the quote. Once the quote is submitted, the approval flow is fixed and cannot be changed i.e. the approval gates are fixed. If workflow has more than one approval gates to go to (in parallel or in sequence), the workflow process will conclude only when all the approval gates are checked (i.e. approval gate owner approved the quote). 1.Logging For debugging and tracing of approval flow on HANA cloud server, administrator can turn on debug log for the following java class files:
3.4.1 Setup steps of Approval
Step 1: Define a condition
Step 2: Define an Approval Gate
An Approval Gate can have multiple Approval Gates. This is how it defines approval in sequence for single or multiple roles. Step 3: Define an Approval Rule and link it with Approval Gate and Condition.
3.4.2 UI Interaction of Approval
Step 1: Under Quote Module > Line Item Under Quote Line Item, under discount column then Apply discount.
Step 2: Under Quote Module > Process Flow After applying, the user submits for Request Input or Approval for this Quotation.
4 How to setup routing
5 Status flow with actions
Sales Document Allowed Actions are determined programmatically by ISS/CPQ. There is no restriction such as only creator can submit quote. Below are the matrixes for quote and opportunity actions per sales Document Status. However, from UI Profile the actions can be hidden for a User Role based on sales document status.
5.2 Quote Actions
6.Partially Sent to ERP Status
7.Sent to ERP Status
5.3 Opportunity Actions
ISS inbox would not be showing both Quote and Opportunity except in the following final statuses: ACCPETED,REJECTED,SENTTOERPandWON. Also, a current logged in user will find all Quote and Opportunity in his/her inbox if he/she is a creator or submitter or owner of that document and the document is not in a final status. In addition to above the current logged will also see those document that need approval if the user is an approver and the Sales Document Status is COMPLETED. For routing users, they will see the document if the Quote is routed to them and the Sales Document Status is OPEN. In case the routed user has sent the quote back (new action sent) he/she can find the quote is sent items of the inbox, so long the Quote status is OPEN.
6.1 Approval and Routing Annotation
All approval and routing information such as who is the submitter, who is the router, whom the quote is routed to, who approved or rejected is also tracked by annotations on the quote.
Permission can be divided into two parts: namely static permissions and dynamic restrictions. Static permissions are permissions that are loaded once the user logs into the system and are next applied on each REST call that user makes on ISS/CPQ. Dynamic restrictions are on the granted permissions. So, for example if a user has a DeleteQuotePermission he or she can be restricted in performing this operation by using a restriction. Which is evaluated at run time.
Static permission can be defined on Role level. Restrictions (Restriction Rules) can be defined either on a User level or on User Role level. Each restriction is defined on a specific permission. Each condition has business type on which the restriction will work. For 1608 release the supported business types for restrictions are Quote and Sales Item.
For 1811 release, all available permissions are defined in Application-schema as follows:
- Create Permission (CREATEPERMISSION)
- Create Quote Permission (CREATEQUOTEPERMISSION)
- Create Sales Item Permission (CREATELINEITEMPERMISSION)
- Create Account Permission (CREATEACCOUNTPERMISSION)
- Create Opportunity Permission (CREATEOPPORTUNITYPERMISSION)
- Update Permission (UPDATEPERMISSION)
- Update Quote Permission (UPDATEQUOTEPERMISSION)
- Update Quote Status Permission (UPDATEQUOTESTATUSPERMISSION)
- Update Sales Item Permission (UPDATELINEITEMPERMISSION)
- Update Account Permission (UPDATEACCOUNTPERMISSION)
- Update Opportunity Permission (UPDATEOPPORTUNITYPERMISSION)
- Read Permission (READPERMISSION)
- Delete Permission (DELETEPERMISSION)
- Delete Quote Permission (DELETEQUOTEPERMISSION)
- Delete Sales Item Permission (DELETELINEITEMPERMISSION)
- Delete Account Permission (DELETEACCOUNTPERMISSION)
- Delete Opportunity Permission (DELETEOPPORTUNITYPERMISSION)
- Flint Permission (FLINTPERMISSION)
- Admin Permission (ADMINPERMISSION)
- All Permission (ALLPERMISSION)
7.2 Permission Hierarchy
If a user gets a Higher-level permission for example CREATEPERMISSION, he/she gets the permission to Create: Account, Quote etc., however if he possesses only CREATELINEITEMPERMISSION he/she can only create that object and not objects such as Account or Quote. Permissions are checked in each REST/Service call. However, restrictions are evaluated for Specific Operations only. For 1608 release these being:
- Quote deletion
- Quote update
- Quote status update (workflow/approval actions)
- Sales Item
- Sales Item deletion
The restriction concept can further be applied in other cases and need be with prior requirement analysis. For example: Based on one or more dynamic attribute value another dynamic attribute value can be assigned, or another dynamic attribute can be made hidden or read only. Similarly using a recommendation trigger, one can suggest to user additional products can be sold as up/cross selling potential.