I opened a Case with Microsoft Support for an issue which seems like an obvious bug, where when you resolve a Case and type something in the “Resolution” field it gets overwritten with “Resolved Case”
This is causing data corruption because we like to keep track of Case resolutions and now any time we close a Case it changes the Resolution to “Resolve Case”
That is not the only issue however, we have a workflow that sends the resolution to customers when a Case gets resolved. We like to have a descriptive resolution that gets sent to them but with this bug (by design change) the email just sends out an email saying that the resolution was “Resolved Case”.
Why would Microsoft even let us type in a resolution when we resolve a case if they are just going to overwrite it anyways?
It would be great if Microsoft CRM could allow the upload of pictures in draft articles, in the Knowledge Base section.
Most of the times, my clients have pictures illustrating the processes to follow and there is no way (except by having another web server hosting the pictures) to include pictures IN the articles.
The case form should display 'title' on Form - instead of case number at top of form.
This is inconsistent with any other entity that I use - All others use the Name as the Title on the form.
Additionally the Outlook Preview pane displays the Title at the top of the form instead of the case number - this is inconsistent.
When a user creats a case and assigns it to a queue, a queue item details record gets created that shows which queue the case is assigned to and who has worked on it. Once the case is resolved, the queue item details record also is inactivated.
If the same case is reactivated again, the associated queue item details record is still inactive thus leaving it unassigned to any queue. If the user tries to assign it to the same queue or a different queue again a new queue item details record is thus created. So the case now has an active and an inactive queue item details record. On clicking the Queue Item Details button on the case form ribbon, a warning message is displayed which states "The record is in multiple queues. Go to the specific queue to view details". Thus the user will now have to manually search which queue the case was assigned to.
This should be fixed. As soon as the case is reactivated, the associated inactive queue item details record should aslo be reactivated so that the it automatically gets assigned to the queue, to which it belonged before being resolved. And the warning message does not show up.
The current SLA/Entitlement design requires an Entitlement to be directly linked to a Customer. Subsequently, on an Incident, either a default SLA is used or an Entitlement is selected - based on the Customer's created entitlements.
The issue that exists is that the KPI metrics and rules exist at the SLA level, not the Entitlement. Many support organizations only wish to apply the SLA rules, and do not enforce their support contracts via entitlements - their terms and conditions are date driven. For instance, any number of hours or tickets for calendar year 2015, et. al.
Secondly, because Entitlement require a customer, and these entitlements reference SLAs with differing rules - in order for the SLA rules to be enforced, entitlements must be created for each customer. This requires custom code to create entitlements for the companies (development time and support) and generates unnecessary data growth.
Consider this scenario: a company has 50K accounts, and also has 10 different SLAs, and each has their own KPI rules and events. A company may need to use any one of these SLAs, but in order for that to occur, there will need to be an Entitlement created for each Company. This results in 500,000 entitlement records that need to be created! This is unnecessary, and for an online customer - directly results in data volume costs PLUS the develop costs to automate the entitlement generation. Entitlements which the company does not need.
A revised design proposal for SLAs:
1. Remove the requirement that an entitlement require a Customer, thus allowing a non-customer specific Entitlement to be selected on any Incident
2. Allow SLAs to be directly selected on an Incident where an Entitlement is not relevant.
With these two changes, this allows a support organization to more easily apply SLA logic without the need to generate entitlements.
Users are unable to maximize the Schedule service activity window as are able to see less records and wants to view at least 250 records (or as per user’s personal options) in the available times in Schedule service activity window.
If there are more than 100-200 records then as there are only few records visible in window the user will have to clicks on next >1,2,3 page several times
Repro steps: Navigated to service > service calendar > service activity and schedule and the window is the same size in all browsers
when I convert a tracked email to a case, it does not follow the same logic and mapping as the case creation and routing rules. This should have the same options as the case creation rules introduced in SP1.
It should be possible to set up filtering on the subject tree to only display relevant items. For example in an business where differen case forms are created for their respective business units, it should be possible to filtering based on the form to only allow the selection of subjects that are eligible based on the case form.
The size of existing dialog boxes can be really small, and there is no supported way to achieve this.
It would be really great that if users are allowed to modify the size of dialog boxes.
CRM Online Version : 2015 & 2016
We have the need to remove optionset values occasionally, most recently status reasons on Lead. The only thing we can do right now is remove the old/unused optionset values, but this means that any existing data using these optionset values will be affected, we will lose these values on historical data. It would be best if there was a way to deactivate optionset values rather than delete them. Having this ability would allow us to make old optionset values unavailable for new records while keeping historical data intact.