Another gem from Scott Sewell:
If you edit the FetchXML query of a view, you can change the view query to an outer join, enabling you to see records “not in,” or records that do not have a relationship.
When you do this, the view is available from within CRM, but cannot be selected for a dashboard view or chart.
The Captain Redlaces workaround:
It’s Friday and time for another USD installment. In this video, we show you how to create toolbar buttons in Unified Service Desk and how to fire an Action Call to perform an operation.
Give us your feedback, all of it: good, bad, and ugly, I’m sure we can take it. Suggest new topics either in comments or by sending your ideas to jar@crmtipoftheday.com.
Another awesome TIL from Scott “Captain Redlaces” Sewell.
Avoid multi-column sections on your CRM forms. (If you’re going to use the Mobile Apps)
If you’re going to use one of the mobile apps in your implementation, avoid using multi-column sections – the layout of these fields will be significantly different from the Web app.
Use multiple column Tabs with multiple sections – rather than a single-column tab with multi-column sections. (Multi-Column sections display in a different sequence (across then down) on the tablet apps and create a ‘mixed-up’ view of the section.)
Here’s a view of a sample record in the Web Form showing the Tab-Order.
Here’s the same form in the Tablet App – notice the how the Tab with 3 Columns translates better to the app’s default layout.
My British colleague Chris Huntingford recently shared with me his proven method of selecting good monitoring terms for Microsoft Social Engagement. We’ll call it the Huntingford Method:
BOOM!!
We now have so many tips coming from Scott “Captain Redlaces” Sewell that the pressure is mounting to add Captain as ah honorary tipster or, at very least, dedicate a category for him. As suggested by the man himself: “TIL”.
If you’re going to use mobile App or Safari – best practice is to include the “Name” field in the view if the view is to be used on a tablet.
It makes sense to include the “Name” as the first column in your views for 2 reasons –
Finding the spot where you can set the filters to determine the CRM records that are synched to Outlook or your Exchange folders isn’t as intuitive as it could or should be.
When in Outlook and you go to File, CRM, you are presented with a screen which gives you the options to set the offline filters. But where is the option to set the record types to sync to CRM when connected via the client?
That is three more clicks away and not readily observable. You get there by clicking on the Set personal Options button and then clicking on the Synchronization tab and then clicking on View or manage the filters …
Set Personal Options
Synchronization using Filters
It’s Friday and time for action calls. No, not calls for action but Action Calls – grease for moving parts of Unified Service Desk. Here we look at Action Calls and how they work. We walk you though the basics of creating and using them.
Give us your feedback, all of it: good, bad, and ugly, I’m sure we can take it. Suggest new topics either in comments or by sending your ideas to jar@crmtipoftheday.com.
Listen to CRM Audio Episode 10. Hear a preview of our Tips From The CRM Tipsters session
Remember me?
Users of CRM 2015 may notice that the “Copy a Link” button no longer appears in CRM forms and views. Email a link does, but copy a link does not.
The reason goes back to the introduction of cross browser compatibility late in the lifecycle of CRM 2011. Since all browsers do not share a common method of copying, the “copy a link” button was not cross browser compatible. So special logic was added to this button to only appear in Internet Explorer.
Fast forward to 2015. The button is still there (if you look at the command bar/ribbon in the Ribbon Workbench. However, if you open CRM in IE 11, it no longer shows up. The reason for this is Internet Explorer pretends to be Firefox and reports itself as Mozilla. In the words of Scott “Mr. Ribbon Workbench” Durow, “navigator.appName returns “Netscape””
Alternatives to “Copy a Link” button:
Adam Vero adds: In CRM 2015, there is no option to get the URL of a dashboard directly.
Workaround: You can use XRMToolbox SiteMapEditor to change the default dashboard for an area. To do this you select the dashboard from a list by name, but SiteMapEditor then shows you the GUID, which you can copy, then close without saving changes.
You can use this to display the dashboard directly, by replacing parts of this URL as needed, including the GUID you just copied.: http[s]://orgname.domain.com/workplace/home_dashboards.aspx?DashboardID={GUID}
With 2013 onwards, this will display the dashboard with no navigation and command bar, so this can be OK to show a display the dashboard on the wall of the sales office, but is less useful as a URL to direct users to the dashboard or use it as an IE bookmark or homepage. If you want to embed this dashboard in an iframe on another dashboard, this seems to work just fine. Old instructions would have you replace /workplace/home_dashboards.aspx with /dashboards/dashboard.aspx in the above URL, but it seems this is no longer any different.
Remember that if you want to embed a dashboard in an iframe on another dashboard, you need to turn off “Restrict cross-frame scripting” for the iframe component. You cannot do this for personal dashboards, only system ones.
Stop the presses! Scott “Captain Redlaces” Sewell, in his relentless pursuit of, er, hm, ugh, perfect CRM, has solved another mystery surrounding the world of mobility.
Appointments in scheduled state appear as read-only on mobile devices.
I’m sure you’re disappointed with the length of the tip, just as I am, so here’s the full story. Straight from the Scott’s mouth:
I’m perplexed.
In CRM I have some appointments that are editable in the web client – but the same appointments are locked and read-only in the Tablet/iPad/iPhone apps. (The behavior is consistent across the iPhone, iPad and Windows Tablet app. )
The user has sysadmin privs, and the activities are not ‘closed’ – but they act as if they are in the apps, but work just fine in the web client. I’ve tried updating the appointments to set the user as the owner/organizer/requiredattendee etc., but these appointments are still locked in the apps.
However, I have other appointments owned by the exact same user that are editable in the web and all three apps. – I’m baffled.
(There are no Business Rules or JavaScripts on the appointments)
Any suggestions on what I might be overlooking?
The helpers arrived in droves. Feridun “Best Twitter Handle for CRM MVP” Kadir made a weak attempt to help by insinuating that Scott does not know his read-only settings, only to be put in line by raging Captain arguing that, had he had this setting on, all appointments would have been locked, and not some.
Suggestions were coming thick and fast. Javascript, security, PBL, you name it. Best attempt of incorrect forms order came from Roohi “Whisper” Shaikh but even that was rejected by rampant Scott who did however verify the order of the forms before sending another helper packing.
A bit of insider knowledge does help and finally Dileep Singh stepped up to the plate and served Scott with
… are all the appointments which are non-editable are in scheduled state ?? Can you check that one.
Whale oil in the storm was that as Scott went all limp but happy:
YES! That’s the pattern I was overlooking – 2 points to Team Singh!
Then the Captain left the podium but not before serving the next one:
So – why is “scheduled” valid in the web – but not ipad?
¯\_(ツ)_/¯
So you are creating an entity in Dynamics CRM and you need a user lookup field. Why not just re-label the owner field? Sure, it is not specifically a record owner, but we don’t really need that for this entity anyway, as we will never tie security to it, right?
Don’t do it! Chances are you will regret it down the road.
Never say never. You never know what will happen in the future. Your little custom entity may grow, or your CRM environment may grow to be used outside of just your group. When this happens, you may well want to have security limitations on the entity, and if the owner field is used for a non-security related user lookup, this will force you to do rework in the future.
Also, if you use the “owner” field for non security related user lookups, you make “assign” permission required to change that field. This may not sound like a big deal, but it can be. Two years from now, you decide to add a child entity with a parental relationship to your custom entity. You set security on this entity, as you don’t want other people changing the data in it. Now when users try to change the user lookup on the parent, they get a “permission denied” error because the user changing the user field on the parent entity does not have assign permission the child.
So if you need a user lookup field for a user role that is not a traditional record “owner,” take a few second and create a custom relationship
of the