Tip #293: What’s the point?

Welcome back to the Tipping Truckstop, where the tipsters gather to discuss pressing CRM matters. It’s DeCRMber already and the trucks are all festively decorated for the holiday season, so grab a cup of eggnog and pull up a stool.

truckstop
Today’s question is: In CRM 2013 and 2015, we have a field data type of “Floating Point,” and also “Decimal.” When is it best practices to use decimal, and when should you use floating point?

Joel “Tipping isn’t just for cows” Lindstrom: I’ve noticed that Floating Point cannot be used with calculated fields, so that would mean that if you need a calculated numerical field that is not whole number, you need to use decimal.

Feridun “Bond” Kadir: Floating Point uses a little less space, calculates slightly faster but at the price of loss of accuracy in the last decimal place. Most times this doesn’t matter, but if you need accuracy to the 10th decimal place then use decimal.

Adam “Beach” Vero: Generally floats are fine, use decimal for rocket science, quantum mechanics or quantities that might be very very small (I had a client recording water purity samples in a database once – they might have needed to record even 1 part per million or less of a toxic chemical). Note also if you might use queries based on equality, decimal is preferable. If using floats, try to use less/greater than or equals to avoid errors in that last decimal place. One thing I have always tried to bear in mind is if the field is involved in integration to/from another system I try to match data types to avoid type conversion (especially if it might be subject to round-trips that can exaggerate any inaccuracies).

Shan “Grillmaster” McArthur: The floating point number format was invented so that computers could work with very large and very small numbers (think of astronomical distances and sizes of atomic parts).  Floating point numbers are an approximation because they only have so many bits to store their data in.
Float1
The above screen shows that CRM does not know how to handle floating point numbers.  The first problem is that there is a precision here, but the precision here has the wrong implementation.  In SQL, the precision of a float is how many digits are in the mantisa using scientific notation for the number format.  In CRM, it is treating it like a decimal type and determines how many digits after the period.  This is wrong.   The second problem is that the CRM UI limits you to a maximum of 5 decimals for precision. This goes against absolutely everything a floating point number requires.  Then consider that there is a maximum value.  Floating point numbers in SQL have a maximum value of 1.7976931348623158E+308 and have the smallest value of 2.23E-308.

Here is the maximum value in CRM.  Notice that you cannot even record the budget allotment that was just approved in the senate this week for the US budget:
Float2
This represents a maximum value of 1.0E11.  That is *much* smaller than 1.79E308.

Then let’s look at the CRM UI.  The CRM UI can handle it if you enter a float in scientific notation, but it will change it to a standard decimal format. So 3E5 will get changed to 300,000.00.  1E-1 will get changed to 0.1.  Unfortunately, the limitations of large and small numbers that are imposed on us in the configuration screen are definitely there.  Entering 1E-5 will change to 0.00  1E15 will trigger an error.

The good news is that the value is still stored in SQL using a float column.  It is good that it is stored in a float because that means that the only bug is all of the display logic and data modelling that goes along with it, but that the underlying database is capable of storing that number.

Here is the connect item that I put in for this issue back in 2011: https://connect.microsoft.com/dynamicssuggestions/Feedback/Details/677405

My guidance is that float has more restrictions than decimal, so use a decimal instead.

David “Straw” Berry: I completely agree on all points, floating or otherwise.

George “Untalkative Bunny” Doubinski: More eggnog please.

Tipp Jarr’s Double Dipp

That’d be all, folks, for 2014. Happy New Year 2015It’s been a fantastic year despite being a Green Wood Horse one. Tipsters celebrated a year in business that overflowed the byte originally reserved for the post count. CRM 2015 is alive and kicking and we can all take a well-deserved break only to spend it dissecting and analyzing the new goodies.

Tipsters will be back on January, 5th, 2015 with another year of tips, tricks and truckstops. Drink safely and drive in moderation.

Dynamics CRM Tipper
The Custodians of The Tipping Jar, bringing you tips by a truckload

Tip #292: Licenses minimus

According to the screenshot, CRM Online Enterprise PurchaseFeridun “The Fifth Beatle” Kadir was literally one minute from his new CRM Online account. He hesitated though, quite unsure about the small print on the deal:

The minimum number of professional licenses for a new subscription to CRM online is 5.

But the screenshot suggests a company can sign up for a new subscription with just one enterprise license and nothing else.

Is this true?

Imad “RTD Advocate” Yanni donated some of his time to clarify:

Customers purchase CRM Online Professional and/or CRM Online Enterprise licenses as different subscriptions. If they purchase Professional then there is a minimum limit of 5, if they purchase Enterprise, there isn’t. If you tried buying one or both of them, you’ll see that the product user interface enforces the limit when required; for example if you purchase Professional, the quantity starts with 5, if you reduce below 5 it shows an error and you cannot proceed with the purchase. If you purchase Enterprise the quantity starts with 1.

The minimum is per subscription type so whenever you purchase Professional you need to start with 5 even if you had an Enterprise subscription with 10 licenses.

Tip #291: Disabled Views and CRM for Tablets

In Dynamics CRM, if you have a system view that you don’t want users to see, you can deactivate the view in customizations. That means that the view will not appear in the CRM view selector. Except for in the tablet app. You see all views, even the disabled system views.

This has been fixed in CRM 2013 SP1 UR1. if you are having this issue, install UR1 for SP1 (or later).

 

Tip #290: The paths we choose

While fiddling with the workflows in a freshly minted CRM Online organization trying to find out what else we can do now that we couldn’t do before (like OR condition, this sort of stuff), I came across of this new, interesting and very much undocumented field called Traversed Path:
Traversed Path field

After playing with it for X minutes I can report that it returns a comma-separated list of GUIDs of the stages of the business process flow that the entity “went” through. Why would we need a list like that and couldn’t we just figure that from the flow definition? Not with the awesome new feature like business process flow branching where some parts of the process may or may not be executed.

In a nutshell, it’s a less glamorous, less visible and most certainly less developer-friendly server-side counterpart of getActivePath client-side function. If this attribute was ever defined in the documentation then definition probably would have been (to borrow and paraphrase):

The read-only TraversedPath attribute represents stages currently rendered in the process control based on the branching rules and current data in the record.

The actual traversed path that is used by the system is in BusinessProcessFlowInstance entity. It also has a TraversedPath attribute but this one is not accessible as this entity marked as internal. The <entity>.TraversedPath attribute only stores an entity specific copy and it is used only to understand which stage of the entity to show as selected stage when the record is open.

I am not convinced though that this “surfacing” of the path is intentional (it’s not possible to hide or suppress attribute from the metadata though) and won’t disappear or at least marked as “internal use only” at some point in the future documentation. Until then, go for it (read-only!) and let us know if you find it useful.

Tip #289: Security needed to pick and route queue items

Update  CRM 2013 SP1 changes the Queue “Work On” button to “Pick.” Before SP1, when a user clicked “Work On,” the queue item “Working On” field would be set to the user who clicked the button, but the record in the queue would remain assigned to the original owner. Post SP1, clicking “Pick” not only sets “Working On” to the user who clicked the button, but also the case/activity/record in the queue will also be assigned to the user who clicked the button..

Users must have at least user level assign permissions on activities to pick records from a queue. Assign permission is also necessary to route items in the queue.

 

Tip #288: Remove event handlers Texas style

Today’s developer productivity tip comes from Mitch “Texas Baby Oil” Milam.

The fastest way to remove all of the Event Handlers from a form is to remove the JavaScript Library or Libraries associated with the form.

Removing the library will also remove any event handlers (OnLoad, OnSave, OnChange, etc.) that have been associated with that library. This is very helpful when migrating JavaScript or performing a Form Merge operation.

Tip #287: Prevent meeting notes from going to customers

I recently lead a webinar about the new features in CRM 2015, and one of the attendees asked a great question:

“Is there anything new in 2015 that can prevent server synchronization from sending an update to meeting attendees when the description field is updated? Users record their notes in that field, and we don’t want negative comments about a client being sent to the client.”

This is a good question, because many people don’t realize that Server Synchronization broadcasts meeting changes to attendees. With Outlook synchronization, changes to meetings are not sent to attendees unless someone in Outlook chooses to send an update. With server synchronization, meeting changes are sent out to attendees, even if the meeting occurred in the past.

But there are things that you can do to prevent sensitive notes from being sent to a client.

  • Don’t use the Description field to record meeting notes. Besides the risk that the sensitive notes may get sent back to attendees, the other down side is that this field is just a massive long text field. What if you and two other users update the record? Your notes may get overwritten, and are not time/date stamped like standard CRM notes.
  • Add the Notes pane to the CRM Appointment form. If you add the Notes control in customization, you will be able add date/time stamped notes to an appointment, and these notes won’t be sent back to the attendees. This will also make the experience consistent with adding notes to other CRM records.

test appt

  • If you have CRM 2015, you can configure the outlook synchronization pipe to prevent body/description field changes from synchronizing back to Exchange (and getting sent out to attendees).

sync pipe

 

 

Tip #286: Another way to get notifications

Back in Tip 276 we talked about how to get notifications if you weren’t an administrator.

It recently came to my attention that Microsoft has added a “notifications” button to the CRM Online organization properties. From here you can add additional users to get notifications for the organization. For example, when there is an update to be scheduled.

notifications

Tip #285: Going personal with Microsoft Dynamics Marketing

Mark “Bald as a Kiwi” Smith asked the other day:

I am working with a global bank that is considering implementing MDM (Microsoft Dynamics Marketing – t.j.).

I need to provided them documented information on how PII (Personally identifiable information – t.j.) data is handled with MDM. They currently run CRM2013 on premises.

Roger “Wicked keeper” Gilchrist was quite generous to share his experience that is both thorough and eloquent. If I knew enough about MDM, I couldn’t have said it better myself. Without further ado:

I’ve actually been working with a number of enterprise customers around this. Working with a number of banks on exactly this and have a number, <deleted> being the most public example, where they do this already.

Most of the discussions eventually have come down to a few key points:

  • The data you need to put up in MDM to communicate with customers e.g. via email, is information you’re eventually going to send over the internet anyway when you do the email send, so name, email address for example is all information that will eventually be sent over the internet, so the concern over storing that in MDM in the cloud becomes diluted and rarely a real regulatory or compliance issue at that point
  • Where it can sometimes get more tricky is around sensitive data they want to use to segment the customers. If this is a concern, what can be done is to do the segmentation inside your CRM system and generate a marketing list with the results, and just sync the resultant marketing list to MDM,
    • so you may have a marketing list which is called ‘New product X campaign – Dec 14’ ( which doesn’t give anything away but is directly linked to the communication) or a less discrete ‘High Net worth individuals’ which can be targeted in multiple campaigns without exposing exactly on what basis that determination was done
    • The advantage is you can then do the segmentation on-premises and the underlying data never leaves the premises but the resulting target list and communication in MDM
  • The other reality of this, is that the vast majority of marketing players in the market are also online based, obviously particularly so for electronic communication, so where you use alternative vendors they will hit the same issue and often already are without necessarily realising it.
  • You then have a choice how much additional information you put into MDM to do further communication or segmentation in MDM itself, but that is a choice, but with the two combinations above you typically hit the main scenarios that are of immediate concern

That’s a conversation we’ve had with a wide range of enterprise customers, including those in the FS (financial services – t.j.) sector and deploying successfully based on those principles.

Tip #284: Entities not available for CRM for Tablets

I am a big fan of CRM for Tablets, but like any application, the CRM tablet app has some limitations. Does this make it bad? Absolutely not. What it does mean is that you should be aware of these limitations and avoid potentially costly surprises.

Most system entities and all custom entities can be included in CRM for Tablets, but there are a few entities that are not enabled for CRM for Tablets.

The following system entities are not enabled for CRM for Tablets. Most of them cannot be enabled, except for Mailbox:

  • Attachment
  • Audit
  • BusinessUnit
  • Calendar
  • Campaign
  • CampaignActivity
  • CampaignResponse
  • Contract
  • Equipment
  • Fax
  • Goal
  • Import
  • Invoice
  • KbArticle
  • Letter
  • Marketing List
  • ListMember
  • Mailbox
  • Position
  • Post
  • PostComment
  • PostFollow
  • PostLike
  • PostRegarding
  • PostRole
  • Quote
  • Report
  • SalesLiterature
  • SalesOrder
  • Service
  • ServiceAppointment
  • Site
  • Subject
  • Workflow

The following system entities are enabled for CRM for Tablets, but are read only and cannot be made editable.

  • ActivityMimeAttachment
  • ActivityPointer
  • Annotation
  • Email
  • Entitlement
  • Product
  • Queue
  • SystemUser
  • Team
  • WebResource