I wanted to highlight why it’s such a good thing being able to achieve this. From a business perspective, it means developers can focus on more complicated projects that have the requirement to write custom code and produce functionality that cannot be achieved using standard features, ultimately increasing productivity and revenue. Another reason is that by using standard functionality, it is more likely to be upgradable and you don’t have to worry about it being depreciated or unsupported in updates. Lastly, its very easy to change most configurations such as business rules and business process flows following feedback from a customer if required.
I’ve designed this solution from scratch and for the purpose of this blog post to demonstrate the powerful functionality of an XRM solution that does not contain any custom code or complicated functionality. It takes advantage of some the latest CRM 2015 & CRM 2013 improvements to deliver a simple yet useable functional solution that allows a user to request holiday & TOIL and track their remaining holiday submitted through the CRM 2015 system.
This solution is really just the beginning of what you can do with the out of the box system. This guide can be modified as you see fit. I’ve also even included some ways to extend this solution further at the end of this post.
The solution uses:
- Branching Business Rules
- Roll up fields
- Calculated fields
- Real Time workflows
- Field Security
- Views & Dashboards
- Custom entities
- Standard Workflows
Step 1. Create a Solution & add the ‘User’ entity.
Unmanaged solutions allow you to be able to focus your work and keep it clean, tidy and easy exportable. All changes are still made in the default solution and even if you delete the solution it still remains in the default and must be removed there as well. When prompted, do not include required components.
Step 2. Create the ‘Request’ Entity
You can remove all of the ticks in the configuration boxes and leave the Note functionality to keep it clean, but this is up to you. I have not included it in any of the areas of the site map as I wanted it so a user can only make a request from inside a user record. (Their user record).
Step 3 – Create the fields for the ‘Request’ entity
Create the following fields:
- Request ID – Single line of text
- Date From – Date & Time
- Date To – Date & Time
- No of Working Days Requested – Decimal to 2 places
- Is this TOIL? – Boolean
- Toil Description – Multiple Lines of Text
- Urgent? – Boolean
- Manager Approved? – Boolean
- Manager Signed – Single line of text
- Finance Approved? – Boolean
- Finance Signed – Single line of text
- Status Optionset – Pending, Manager Approved, Manager Rejected, Finance Approved, Finance Rejected, Closed
- Created On field to be changed to ‘Requested On’ label and the field so it shows in views
- User – Lookup to User entity (Mandatory so on the subgrid when you click ‘+’ it opens a new form)
Step 4. – Create fields on the User entity
Create the following fields on the User entity:
- Holiday Allowance – Decimal to 2 places
- No of Holidays Requested – Rollup field (Configuration: Keep the source as it is, Related entity = Requests(User), Filters are if User contains Data (Defensive check) & if ‘is this TOIL?’ = NO), Aggregation = SUM of No of Working Days Requested)
- No of Holidays Remaining – Calculated field (Configuration: No condition (empty) – Action = Set ‘No of Holidays Remaining’ to ‘Holiday Allowance’ – ‘No of Holidays Requested’)
I also created a Requests sub grid and placed it below the fields.
The idea is that you calculate the Rollup Field using the refresh icon to the side of the field (or wait the allotted time – 12 hours by default), and then this will update the calculated field when you fresh the form – so the Calculated field is dependent on the Rollup field.
Step 5. Test your functionality
Its always good practice to test functionality in milestones as you create it as opposed to all at the end. This is especially important (and actually easier!) with configuration as you can then rest assured you can move onto the next step comfortably knowing your previous steps are working perfectly. It’s also a good change to note down some new improvements or additions to your functionality that you may not have thought of that you can implement later. Its kind of like ‘Agile Testing’ – Test often and in phases.
So, take a look at the screenshots below – if you are following the guide you should also have the same. Everything is looking good. We know we have some views to configure & some additional columns into which we will do into a later stage, but the next step is to implement the ‘Request ID’ real time workflow. I made a guide on how to do this in a previous blog post here. What we are going to do in this guide is a very slimmed down version as we only want one prefix – ‘REQ -‘.
Step 6. Create your Real Time Workflows for the ‘Request ID’
Follow the guide here which I’ve posted previously. Again it’s flexible so you can do whatever you want – I’ve included the steps below for a simple version of this without the global option set prefixes. I went for something different and had a decimal field for my incremental number but you can keep it standard and go for whole numbers if you want.
a) Create two new custom entities, Auto Number Request & Auto Number Response, they must have their ownership to organisation, remove all additional functionality tick options and make them available via ‘Settings’.
b) Create the fields for Auto Number Definition first – ‘Increment By'(Decimal/Whole Number), Prefix (Text), Last Number – same type as ‘Increment By’ and place them all on the form, you should also have a ‘Name’ field which is fine.
c) Create the fields for Auto Number Request – Auto Number Definition (Lookup), New Number (Decimal/Whole Number), Prefix (Text) – Place these fields on the form along with the ‘Name field as well’
d) Create your Auto Number Definition record (only one) e.g. ‘Name = ‘Auto Number for Request’ – Increment By = 1.00, Prefix = ‘REQ – ‘ and Last Number can be ‘10000’.
e) Create one workflow on the Request entity, convert it to a real time workflow, and you want it to start on creation of a Request record. First step is to create an Auto Number Request, and populate the ‘Auto Number Definition’ lookup with the record you created in your first step, put an arbitrary name.
f) The next steps are to update the Request with the number your workflows have produced, and we will do this in two steps, first Update Request – when you open the blank Request Form, go to the workflow designer and scroll to the bottom under ‘Process’ and you’ll see your workflow object, select it and use the field ‘Prefix’ then create a second line which is the same to Update the Request but this time you need to change the ‘Set to’ to ‘Append to’ in the workflow designer and do the same thing as above but select ‘Last Number’. Create a final step to Stop your workflow.
g) Next step is to create a second workflow but this time on Auto Number Request, on the creation of and convert it to a real time workflow. The first step in this workflow is to Update the Auto Number Definition ‘Last Number’ record by what number is in the ‘Increment By’ field – do this in the workflow designer (change ‘Set to’ to ‘Increment By’).
h) Finally, the last step is to update the Auto Number Request with the ‘New Number’ which is the Last Number from the Auto Number Definition, and the Prefix which is on the Auto Number Definition under ‘Prefix’. Create a final step to stop the workflow.
Once you have completed these steps test your auto numbering – if you find any errors go back over each step and ensure you are correctly populating the new records your making in the real time workflows – these are the normal places where things get accidentally missed out.
Step 7 – Configure Views
The main one here is the ‘Request View’ – I’ve modified it so I can see all the fields – for the sub grid i was using ‘Active Requests’ and to change the associated view you have to modify the ‘Request Associated View’. See them both below:
Step 8 – Configure Business Rules
Below are the business rules we are going to implement as part of this solution:
- The Request ID is the same as the Name field (then we can hide the name field on the form)*
- TOIL description visibility – if the ‘Is this TOIL?’ is checked this will change the visibility of ‘TOIL Description’.
- Statuses – vs Manager Approved, Finance Approved – These are done in two separate business rules
- If the owner and the user are not equal – throw an error and do not allow save. This is so people do not make Requests for other people, you can modify a security role so they can only have the ability to make a request where they are the owner, and so this should prevent this from happening completely in addition to this business rule.
*You will find an issue with the first one – you will notice even with the business rule activated it still asks you to fill in the ‘Name’ field as the workflow has not kicked off yet (technically the Request ID is also not filled as part of the BR logic) – there is an extra step for this and it is to create a field mapping in the Request/User relationship so the ‘First Name’ is mapped over to the ‘Name’ field on creation of the Request when it is created from within a User record. (This is the only way to create one as we have not put Request on the Site Map)
What will happen is the name will copy over but once you click ‘Save’ the auto number will generate and there will be unsaved changed again – but once you close the auto save will pick these up and update the ‘Name’ field for you – or if you just go straight to ‘Save and Close’ the ID is automatically updated into the ‘Name’ field.
Step 10 – Adding field security on Holiday Allowance, Manager Approved and Finance Approved.
Adding field security can be done a few ways, so the way I’m gong to do this isn’t the ‘only way’ – I would create two field security profiles (after enabling the three fields for field level security which can be done in the field itself) – with one profile for the general users which allows them to read but not write into these fields, and manager which allows all edit permissions.
Step 11 – Creating email workflows
Create an email workflow when a new Request record is made to the ‘Manager’ lookup on the User record that a new request has been made for. This does mean the ‘Manager’ lookup needs to be filled on all ‘User’ records which you will notice is read only. This can be modified by going to the ‘…’ extra commands and selecting ‘Change Manager’.
Step 12 – Adding Icons, Making Dashboards and more Views
The final step would then be to add some more views as desired, perhaps even a Dashboard for a User/Manager/Finance. They can all have a list view of ‘My Pending Requests’ ‘My Approved Requests’ ‘My Rejected Requests’ (Has ‘Rejected Reason’ in it)
- Manager – ‘Pending Staff Holiday Requests’ – expose the ‘User field’ & ‘Pending TOIL Requests’
- Finance – ‘Pending Requests’ – a view of all requests where ‘Manager Approved’ = Yes
Adding Icons is easy and just requires you to go to the entity and select ‘Update Icons’ (see the screenshot below)
Ways to extend this solution further
‘Unapproved’ & ‘Approved’ calculated and rollup fields: At the moment the solution doesn’t differentiate between holiday requests that have been approved only made. This could be split into two groups of two each – so have a rollup & calculated field which only looks at the requests that have a ‘Pending’ Status. The second set of two would have a second calculated field and rollup field which would only look at requests that have the ‘Manager Approved’ status.
TOIL Request count: The solution only looks at requests which are not TOIL as this should technically not be removed from any holiday for the year. However it would be advantagous to be able to keep a count of how many TOIL days have been requested – this could simply be a rollup field of ‘TOIL Days Requested’ and it would look at ‘No of Working Days’ field on the Request entity and have the additional condition that the ‘is this TOIL?’ field set to yes.
A Dialog process: of selecting multiple records that ‘change the ‘Manager approved to Yes’ and then provide a text field to input what they want in the ‘Manager’ field. E.g. Sarah Critchley to be applied to all of the selected records. – as a way of approving multiple records at once (the request view would have the
Rejected reason: Additional Logic could be added so that if the status is set to either ‘Manager Rejected’ or ‘Finance Rejected’ it displays a ‘Manager – Rejected Reason’ field and a ‘Finance – Rejected Reason’ which are mandatory. This could easily be achieved with Branching Business Rules.
I hope this has been helpful and if you are following this guide and have any questions please leave them below in the comments.