@CRMUG Get2Know CRM 2015 Covering the Field(s) - Rollup and Calculated Style

@CRMUG Introductions  Steve Ivie  Solution Architect, Tribridge   LinkedIn: \stevemivie BIO:  7+ years of Microsoft Dynamics CRM, ERP, SharePoint, BI Experience  15+ years of business systems architecture experience – Microsoft, Oracle, etc.  Design business solutions with Dynamics CRM and Office 365 that address Sales Productivity, Social Collaboration and Business Analytics  Author of ‘Building Dynamics CRM 2015 Dashboards using Power BI’ on shelves this May 2015

@CRMUG Dynamics CRM 2015 has introduced the ability to create calculated fields, which can automatically sum numbers, do some date math, and perform string manipulation also introduced rollup fields that can summarize and compare values from related child records. Come see how easy it now is to: Find the next expected close date across all of the opportunities linked to an account; Solve that “not in” problem and find accounts without any open activities; and Create an account profile that shows how many open cases, opportunities, or activities are in progress for this, and each, account. We’ll also cover the limitations, so you’ll know which problems these new features solve, and which still remain. Calculated and Rollup Fields

@CRMUG Calculated Fields : Capabilities Calculate Numbers, Text, Dates, Option Set or Y/N fields From Current or Related Child Entities Using Operators: – + - * / – Concat, TrimLeft, TrimRight – Add/Subtract Days/Weeks/Months/Years Can set Conditions (Open Opportunities) Calculations done in real time, on form (or view) open Uses custom SQL functions in a computed field data type

@CRMUG Calculated Fields : Limitations Calculated fields are NOT stored! So you can’t: – Do rollups of calculated fields – Use them to trigger workflow (wait event, e.g.) Does not trigger a save, so no modifiedon change, no Auditing! Max of 5 chained fields; max of 10 on views All fields involved need to be on the form Not available offline

@CRMUG DEMO

@CRMUG Rollup Fields : Capabilities Available for whole number, decimal, currency and Date/Time Can use a hierarchy to rollup to parent accounts, e.g. Select a child (1:N) entity. You can set a filter on the Child entity (only open opportunities) For numbers: SUM, MAX, MIN, COUNT. For date fields: MAX, MIN CAN sort on them

@CRMUG Rollup Fields - Limitations No rollups of rollup fields! Cannot be used for workflow wait conditions Max of 10 per entity, 100 per org Only 1:N relationships supported, not N:N Does NOT update modifiedon Aggregation done by system account; may be confusing if using org security to hide child records.

@CRMUG DEMO

@CRMUG Additional Information The formula editor assists with entering valid fields with type-ahead for field names (“Intellisense”). These fields are not filtered by type. For example, if you are creating a currency rollup field, text fields will appear in the list, but if you attempt to use one of them improperly, you will get an error message telling you that you can’t save the current definition. Using Intellisense results in the selected field being added at the end, not where the cursor was. Creating a calculated field appears to immediately set the value for all records. Calculated field values are persisted to the [entityname]Base table. If any of the fields included in the calculation are null, the calculated value will also be null. Unfortunately, there doesn’t appear to be a function to supply a default value to avoid that case, so it will either need to handled for the dependent fields themselves or with an exponentially increasing (for each dependent field) set of conditional statements within the formula. Using a decimal field within a whole-number calculated field results in the decimal value being rounded rather than truncated. The rounding occurs on the final value, rather than on each individual decimal field. So, * 25 = round(12.34 * 5) = 309 instead of round(12.34) * 25 = 300.

@CRMUG Additional Information (continued) The division operator is a forward slash (/) not a backslash (\) and the multiplication operator is an asterisk (*) not an x. The string literal character is a double quote (“), not a single quote (‘). Modulo (percent symbol) and power (carat) operators don’t appear to be supported, but grouping mathematical operations with parentheses is. You can include decimal or whole number, but not date, fields in calculated string fields, but I couldn’t figure out how to control the formatting. If you use the field value directly, the decimal value is included without the currency symbol and with the precision defined by the source field (e.g. a calculated field that is CONCAT(“Total Revenue is “, total revenue) will show something like, “Total Revenue is 37.34”). However, if you perform a mathematical operation on the numeric field, it shows 10 decimal places (so, if total revenue is divided by 2 in the formula above, the result is, “Total Revenue is ”). When creating a formula for a single line of text calculated field, single line of text fields with their maximum length set to the field maximum (e.g. 4,000) cannot be used. However, if you change the max length to 3,999, add it to a formula and then change its length back to 4,000, the system will use it in calculations, with anything past 4,000 characters in the result being truncated. When you open the formula again, you will get an error at the top saying too-long field doesn’t exist. Not a surprise, but you cannot delete a field that is referenced in a calculation, even if it isn’t used anywhere else in the system (e.g. forms, views, etc.). This is definitely nice, since there is no such check when you are writing a plugin.

@CRMUG Field Use and Aggregating  Calculated fields are actually virtual fields that are NOT stored in the database. However, they can be used and displayed like any other physical field in views / reports / charts / forms / Field Level Security.   Calculated fields are calculated synchronously after a Save is performed. The end user will get immediate feedback that data has changed after the form is refreshed.   Rollup Fields are actually virtual fields that are NOT stored in the database. However, they can be used and displayed like any other physical field in views / reports / charts / forms / Field Level Security.   Rollup Field is calculated using asynchronous jobs. This is performed automatically every hour, but if you’d like, you can kick off the calculation manually by hovering over the rollup field on your record form, and clicking the icon of the two arrows on the right of the field that states “Recalculate” when you hover over the icon. You can also use the API to recalculate rollup fields on demand using code.  Reference: 

@CRMUG Thank you Steve Ivie Solution Architect, Tribridge | LinkedIn: \stevemivie