Share:|

                                   

           

In this blog we will talk about one of the important aspect of Remedyforce configuration, how to make fields required to get right data. BMC Remedyforce is one of the powerful tool built on force.com platform. The platform gives lot of flexibility.  The success of Remedyforce implementation  is based on right foundation data setup along with industry best practices.

 

Let’s first understand why to make fields required?
  • Reporting – Imagine your boss or management  wants a report at end of month and the data does not exist as it was never populated. As they data was never captured, you can’t create required Reporting matrix.
  • Workflows or Automation – You may like to route records based on criteria  for example from Self Service you would like to assign Incidents based on Parent Category to specific Queue.
  • Email Alerts – You are sending email notification with  fields information however the fields are never set. The email notification is blank or incomplete. This is one of the common issues resulting in sharing incomplete and missing information with users.
  • SLA –  Most of the time SLA would be applied based on priorities or some criteria. You may like to make field required. Say your SLAs are on priority however Impact and urgency are not required resulting in SLAs not being applied
  • Data quality – Improves data quality and helps to get right and standard inputs from user.

 

What are ways to make field required in BMC Remedyforce

 

1.Field Level

You can make certain fields required on database level. You will hardly do this as Remedyforce admin. Note if you do this then this would be make it required irrespective of if field exist on the form or not.  Do not use this option as this will make field mandatory on module.

Use case – adding a new object or custom module where the say number is always required

 

2. Page Layouts or Field Set

These are based on layouts, this is most common way of making fields required and easiest way for Remedyforce administrator. Makes it required on first save/create.

Create > Object > Field Set> Double Click on field > double click on wrench icon

Use case – Make fields required on Console layouts

 

3.Validation Rules –

This is another way of making fields required conditionally.  This gives ability to make any fields required on selection of value in another field when record is Saved.

Create > Object > Validation rules

Use case - Resolution required on closure.

 

 

4. Service request

You can make fields required in the service request module in 2 ways.

Most common way - There is "Required" check box on Request definition configuration. Also, some field types like date and numbers may have Validate options to write simple validations easily.

Example- Make Start Date required on New Hire form

 

Using validation rule - You can also write normal validation rule which you can write to make Service Request fields required. This is great as gives ability to use powerful validation rule capabilities of Salesforce platform. You can use field mappings to store data and then apply validations. I will share detail steps in of the upcoming blogs.

Example – Check box cannot be made required using configuration, in this case use validation rule to make it required.

 

 

Let’s look at some of the best practices
  1. Never make fields required on database level. Option is available when you add new field. You may only need this for new table/object and application. Discuss with admins.
  2. Always check if you want to make field required on SAVE event or conditional. You may make it required on the field set instead of writing validation rules.
  3. Check if field validation applies to an Agent or it's profile specific or user specific.
  4. Always add validation rule which will apply only on open state. This will make sure they don’t trigger on closed records or don’t interfere with data loader updates.
  5. Use workflow rule field updates as an alternative to set values to set values if you do not want user to set values for reporting etc.
  6. Take advantage of Page layouts to create field required for teams.
  7. Always test every rule on sandbox using different type of users.
  8. Too many required fields will reduce productivity and time to close so get inputs from your team in UAT. Also poorly written validation rule can  degrade helpdesk usage.
  9. Instead of combining rules may like to use separate rules in some scenarios to give more clear error messages.
  10. Promote use of “Templates” for common issues, this will help to expedite to set right values on all the required fields.
  11. Keep Service request and Incidents field requirements separate on consoles – you may not need all fields required like Incidents on SR layout.
  12. Keep your agents informed. End users and Agents should be always informed about new validations or required fields and changes.
  13. Deactivate validation rules before data upload. Document them.
  14. Always give precise description and right error message.

 

What are the limits?
You can have up to 100 active validation rules per object for (Remedyforce Enterprise edition)

 

Common validation rules for Incident module

Please note – they any of these rules on Sandbox and test it before moving to production. The data and configuration may vary from org to org and may require changes!

 

Rule

Formula

Error Message

Description

Module

Cannot CLOSED Unless RESOLVED

BMCServiceDesk__Status_ID__c ="CLOSED" && $User.BMCServiceDesk__IsStaffUser__c = True && NOT ( PRIORVALUE(BMCServiceDesk__Status_ID__c) = "RESOLVED")

You cannot CLOSED the Incident unless it has been resolved First

Cannot CLOSED Unless RESOLVED

Incident

Closure Category Required on RESOLVED

ISPICKVAL( BMCServiceDesk__ClosureCategory__c , "" )&&(BMCServiceDesk__state__c = False || BMCServiceDesk__Status_ID__c = "RESOLVED") && $User.BMCServiceDesk__IsStaffUser__c = True

Closure Category Required

You cannot closed or resolved or close  the Incident unless Closure Category is populated

Incident

Resolution Required On RESOLVED

ISBLANK( BMCServiceDesk__incidentResolution__c )&&(BMCServiceDesk__state__c = False || BMCServiceDesk__Status_ID__c = "RESOLVED") && $User.BMCServiceDesk__IsStaffUser__c = True

Resolution Required

You cannot resolve or close Incident without resolution populated.

Incident

Cannot go directly to  CLOSED

PRIORVALUE( BMCServiceDesk__Status_ID__c)= "OPENED" &&BMCServiceDesk__Status_ID__c = "CLOSED" && BMCServiceDesk__firstCallResolution__c = FALSE

You cannot go from OPENED to CLOSED unless its First Call Resolution

You cannot go from OPENED to CLOSED unless its First Call Resolution

Incident

Queue Required

$User.BMCServiceDesk__IsStaffUser__c = True&&ISBLANK( Owner:Queue.QueueName )

Queue Required

Queue cannot be blank on new record

Incident

Staff Required on Closure

ISBLANK(BMCServiceDesk__FKOpenBy__c )&&(BMCServiceDesk__state__c = False || BMCServiceDesk__Status_ID__c = "RESOLVED") && $User.BMCServiceDesk__IsStaffUser__c = True

Staff Required

You cannot close or resolved Incident without staff populated

Incident

Responded Date Must be after Opened Date

AND(NOT(OR(ISNULL( BMCServiceDesk__respondedDateTime__c ),ISBLANK( BMCServiceDesk__respondedDateTime__c ) ) ), BMCServiceDesk__respondedDateTime__c < BMCServiceDesk__openDateTime__c )

Responded date must be after Opened date

Responded date cannot be before opened DATE

Incident

 

 

Tips for Remedyforce admins
  • Want to apply rule only to open records  BMCServiceDesk__state__c=true
  • Want to apply rule only to use $User.BMCServiceDesk__IsStaffUser__c = True
  • Want to apply rule to only Incidents and not service request use  BMCServiceDesk__isServiceRequest__c= False
  • Want to apply rule to specific profile use example $Profile.Name=”ServiceDesk Staff”
  • Want to apply rule for specific user use example $User.Username=”kedar.zavar@cloudaction.com Note – use IDs preferably instead of strings
  • Want to apply rule for specific role use example $UserRole.Name=”RF Staff”
  • You can make attachments required on Remedyforce request definition form see additional options
  • You can also use custom settings with validation rules. This would be covered in future blog.
  • You can also use formula fields for complex validation rules
  • You can easily move validation rules from sandbox to production using change sets

 

What’s next  for Remedyforce administrator?

 

Happy Administration!