Version Control

Reference Documents

1. Functional Process

 Process Overview

2. Data Model & security

Main objects

Contact

1. Case: Standard Salesforce Object to store and manage all general information regarding a Webform, or a Customer Request / Sample Request created against the Webform
2. Account: Standard Salesforce Object to manage the information about the Customer related to the Webform
3. Contact:  Standard Salesforce Object to manage the contact person from the Customer
4. Product: Standard Salesforce Object to manage the Product (all levels) that is related to the Webform
5. Opportunity : Standard Salesforce Object to manage the Opportunity created against the Webform

Webform Security Model

3. Webform Custom Buttons & Features

3.1 Features

Webform Assignments 

Assigning a Webform to a User or a Group of User is to pass the responsibility to act on the Webform on a particular phase of the process. On Salesforce, the Webform 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 Requests with the same criteria).

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

• Manually changing the Owner – at any time, a User with Access to a Webform can click the button Change owner 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 Webform criteria (GBU), to allow the System to automatically change the Ownership of a Webform to a specific User or a Queue when the Status changes (mainly at creation for Webform)

Webform Notifications

On each step of the Customer Request Management Process, a set of Solvay personalities (Salesforce or not Salesforce Users) needs to be notify that a new Customer Request has now moved to a specific Status in order to act (Customer Request 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 Activity History Section of a Customer Request. There are four types of Addresses on the Customer Request Notification 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 previous Owner (if not a Queue) – normally the previous owner is the User that changed the Status and triggered the notification. He/she will be also notified  to ensure that the correct Owner has been assigned
• 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.

Account/Contact recognition

Classic process :

If the email address entered on the webform is an existing email address of a contact in SalesForce, the system automatically links the webform to that contact and to the (primary) related account.

If not, the user will choose one of the following options:

1. "Generate Prospect & Contact" Button : If the account is not existing in the system, the user can generate a new prospect and a new contact using the webform information (entered by the customer)
2. "Generate Contact" Button : If the account exist, once the account is selected (manually) and linked to the webform, the user can generate a new contact using the webform information (entered by the customer)

Lightning process :

If the email address entered on the webform is an existing email address of a contact in SalesForce, the system automatically links the webform to that contact and to the (primary) related account and display the information on the Account/Contact recognition component :

If not, the user will choose one of the following options:

1. Link to existing account using the anchor:  the system will search and propose an account name containing an exact match of the "web company" name entered by the customer and the country (matching with account mailing address country)
   
    
   
   Then, the contact will automatically be created and added on the webform.
   
   
2. if none account is matching, or none retrieved, the user can use the "Create a new Account to link to Case" Button to create a new prospect. The contact will automatically be created and added on the webform.

Conversion process

At any phase of the Customer Request Process, Users are able to Clone Customer Requests to save time on the registration phase. This will open a new Customer Request form already populated with the information from the initial Request.

3.2 Custom Buttons

"Send Answer" Button

On the Processing phase, the User responsible for the communication to the Customer must send Communication Email to the Client with the Proposed Customer Response. The user can send the email by clicking on the “Send Final Communication” button. In addition to the predefined Contact, the user can also input any valid email address as CC, select the Language of the Template and select the Attachments the User wants to send to the Client. 

4. Specific Rules & Automation

Customer Request Registration

In order to create a new customer request, on the Case tab, the user needs to click on the “New” button, select the customer request record type and click on “Continue”. Additionally, customer requests can be found in a related list on the Account page from which the user can see all existing customer requests for this Account as well as creating a new one. When creating a customer request from this related list on the Account page, the record type is by default “Customer Request” and the Account is automatically populated in the Account Name field.

When the user creates a Customer Request, he/she has the ability to register the following information: 

Case Information 

Customer Contact Information

Multiple contacts can be maintained on the Customer Request. The main Contact can be maintained under the Customer Contact Information section and additional Contacts can be maintained in the Case Customer Contacts related list.

The main Contact on the customer request is by default recipient of the communication to the customer. The recipients can nevertheless be changed by the user.

Description

In this section the initial description of the Customer Request is captured

As detailed on the the Approval Process section above, users must at all times submit manually a Customer Request for approval after all the relevant information is provided regarding the Customer Request. When an approval is requested by the GBU the status is changed to Pending Approval and the User or Group of Users responsibel for the approval are notified. When the Customer Request is approved, the status is changed to Approved.

Process the Customer Request

Once the Customer Request is approved, the Users or group of Users responsible for processing it are notified to act on the Case. The Users will provide a description of what was done and processed on this Customer Request that should then be comunicated to the Customer.

Customer Response

Detailing the Response that should be sent to the Customer.

Customer Communication

In order to send the final communication to the customer, there is a button “Send Final Communication” that when pushed will open the template of the final communication email which can be previewed and is editable. 

By default, the email of the main Contact assigned to the customer request will automatically be populated in the recipients fields. It is possible to add any other email address to the list or in CC.

Basic information on the customer request is available in the template but it remains fully editable. Once the answer to the customer is ready, the user can send the email.

The customer request template is available in the following 16 languages (including simplified Chinese and traditional Chinese):

Furthermore, the language of the main Contact is used to determine the language in which the email template will be generated. In case no language is assigned to the main Contact, the default language of the communication is set to English. The user can always change the language by choosing another one in the dropdown list if needed . Attachments on the customer request can be attached to the final communication email to the customer.

Customer Request Closure

Any User assigned to the case team can close the customer request by clicking on the “Close” button. This redirects the User to the closure page where a “Comments” fields can be populated prior to closing the Customer Request. When closing a Customer Request, the status will be default Close/Answered, meaning that the Customer Request was completed and the Customer received a communication. If the customer request was Rejected or has not completed the process, the Status can be changed to Closed/Stopped. 

Close Case

This section groups all the fields related to the Closure phase

The best way to get IT support is to use the new Service One Platform.