Version Control

Reference Documents

folder 03. Business Rules & Queues 

1. Functional Process

 Process Overview

2. Data Model & security

Main objects

1. Case: Standard Salesforce Object to store and manage all general information regarding a Customer Specific Requirement
2. Accounts: Standard Salesforce Object to manage the information about the Customer related with the Customer Specific Requirement
3. Files:  Standard Salesforce Object to manage the Files related to that Customer Specific Requirement
4. Case Team: Standard Salesforce Object to manage all the actors related to the Customer Specific Requirement Process and to manage accessibility to the Case
5. Customer Request Products: Custom Object to manage the Products Level 4 and 5 that are related to the Customer Request
6. Case Account Association: Custom Object to manage the association of additional Accounts (besides the main one identified in the Account field) in the Customer Specific Requirement.

Customer Specific Requirement Security Model

3. Customer Specific Requirements Features

Features

Customer Specific Requirement Assignments 

Assigning a Customer Specific Requirement to a User or a Group of User is to pass the responsibility to act on that record on a particular phase of the process. On Salesforce, the Assignment is based on the field Case Owner.

A Case Owner can be a User (Solvay employee with a Salesforce license) or a Queue (a group of Users that should be part of a team to handle Customer Specific Requirements with the same criteria).

Based on each GBU own process and rules, the Assignment can be performed by:

• Manually changing the Owner – at any time, a User with Access to a Customer Request can click the button Change next to the current owner and select a new User/Queue to be the new Owner
• Automatically selecting the actors – the GBU has provided the rules, based on Customer Specific Requirement criteria, to allow the System to automatically change the Ownership of a Customer Request to a specific User or a Queue when the Status changes

The Actors are managed on the Case Team. The Users are added to the Case Team i) manually by a User or ii) automatically by the System when they are the new Owners of a Customer Specific Requirement. When the Users are added automatically to the Case Team, they are added with the correct Role based on the current Customer Specific Requirement Phase. 

Customer Specific Requirement Approval Processes

After the registration phase is completed by the User and all the information related to the Customer Specific Requirement is provided (General Information, Description, Accounts and Contacts, and Products), the record must be manually submitted by the User to be approved by clicking on the ‘Submit for Approval’ button. Based on System Rules and GBU Rules, a Customer Specific Requirement can be:

• automatically approved - the Status will be automatically changed to Under Assessment and the Customer Request will be assigned to the User or Group of Users responsible for the Assessment.
• assigned to be approved - the Status is changed to Pending Pre-Approval and the User or Group of Users responsible for approving the Customer Specific Requirement will be notified.

During the approval process, the Customer Specific Requirement will be frozen until it is “Approved” or “Rejected”.

If additional information is needed before the approval of the Customer Specific Requirement, or some part needs to be corrected, it can be "recalled" by clicking on the Recall button on the Approval related list. Once the information has been delivered, the request can be submitted for approval again. 

Similarly, when the user completes the Assessment of the Customer Specific Requirement, he has to manually 'Submit for Approval' for a final approval, before the Customer Specific Requirement is implemented by the plants. Based on the GBU rules, the Customer Specific Requirement can be : 

• automatically approved - the Status will be automatically changed to Under Implementation and the Customer Request will be assigned to the User or Group of Users responsible for the Assessment.
• assigned to be approved - the Status is changed to Approval Pending and the User or Group of Users responsible for approving the Customer Specific Requirement will be notified.

Customer Specific Requirement Notifications

On each step of the Customer Specific Requirement Management Process, a set of Solvay personalities (Salesforce or not Salesforce Users) needs to be notified that a new Customer Specific Requirement has now moved to a specific Status in order to act (Owners) or to be informed.

On each Status change, an email is sent from Salesforce to a group of users, based on System Rules and GBU Rules that should be stored and displayed in the Emails related list of a Customer Specific Requirement. There are three types of Addresses that are notified Email when the Status is changed:

• The new Owner – if your GBU has implemented assignment rules and the owner is changed automatically to a specific User or to a Queue, the new Owners will receive the Notification Email.
• The Case Team – all Case Team Members, independent of their Role will receive the Notification Email
• Solvay Contacts on Notification Rules – group of contacts (not necessary Salesforce Users) that are selected to be notified when the Status is changed based on each GBU Rules.

Customer Specific Requirements can be cloned with versionning (Aroma Perf) 

A feature to manage versioning of SCR exists for GBU Aroma Perfomarnce : user will be asked if existing SCR must be de-activated and for which reason  .  

4. Specific Rules & Automation

Registration

In order to create a new Customer Specific Requirement, on the Case tab, the user needs to click on the “New” button, select the Customer Specific Requirement record type and click on “Continue”. Additionally,Customer Specific Requirement can be created from a related list on the Account page from which the user can see all existing cases for this Account as well as creating a new one. When creating a Customer Specific Requirement from this related list on the Account page, the Account is automatically populated.

When the user creates a Customer Specific Requirement, he has the ability to register the following information: 

Case Information 

As detailed on the the Approval Process section above, users must at all times submit manually a Customer Specific Requirement for approval after all the relevant information is provided. When an approval is requested by the GBU the status is changed to Pending Pre-Approval and the User or Group of Users responsible for the approval are notified. When the Customer Specific Requirement is approved, the status is changed to Under Assessment or to Rejected if not approved.

Assessment

Once the Customer Specific Requirement is approved, the Users or group of Users responsible for Assessing the feasibility of the Requirement are notified to act on the Case. The Users will provide a description of what was assessed, provide a Feasibility Conclusion, and finally submit the Requirement for a final Approval.

Feasibility 

Depending of the type of Customer Specific Requirement being assessed, one or more feasibility assessments may need to be completed :

• Analytical
• Industrial
• Supply Chain

Each one of this 3 types have a dedicated section, with dedicated fields :

Feasibility (Analytical)

Feasibility (Industrial)

Feasibility (Supply-Chain)

Once these individual assessments of feasibility are completed, the user must provide a Global Feasibility Conclusion

Global Feasibility Conclusion

Once the Global Feasibility Conclusion has been filled the user must submit the Customer Specific Requirement for a final Approval before implementation of the requirement by the plants.

As detailed on the the Approval Process section above, users must at all times submit manually a Customer Specific Requirement for approval after all the relevant information is provided. When an approval is requested by the GBU the status is changed to Approval Pending and the User or Group of Users responsible for the approval are notified. When the Customer Specific Requirement is approved, the status is changed to Under Implementation or to Rejected if not approved.

Implementation

Once the Customer Specific Requirement is approved, the Users or group of Users responsible for Implementing the feasibility of the Requirement are notified to act on the Case. The Users will provide a description of what was implemented, and finally Activate the Customer Specific Requirement.

Under Implementation

Completion

If applicable, and if provided, the user should register the Customer Feedback on the implementation of his request

Once the implementation has been completed the user should change the status to "Active". The Customer Specific Requirement once active remains in this status until it is no longer relevant or needed. When no longer needed the Customer Specific Requirement status should be changed to "Inactive" (during the clone is also possible to deactivate the current Customer Specific Requirement) 

Note: For Aroma when the Ship to Account, Case Account Associations or Customer specific requests products is changed the Customer Specific Requirement goes back to Implementation. 

Appendix