Description
In Dynamics 365, any field – independent of its type[1] - has a category, with three possible categories:
- Simple
- Traditional fields.
- Contains data that is not based on a formula.
- Example:
- Data enter manually by the user (firstname, lastname, etc…)
- Data enter manually by the user (firstname, lastname, etc…)
- Calculated
- Use to automate manual calculations.
- Example: Full name = First name + last name
- Rollup
- Use to get an aggregate value calculated over the records related to a specific record.
- Similar to using sum, min, max, and count in Microsoft Excel.
- Examples:
- Total open cases in Lausanne: the sum of all cases with status “open” that are linked to an account with an address in Lausanne.
Be aware that once a field is created, it is not possible to change is type nor category. The field should be deleted and recreated with the same logical name.
The calculated fields contain a calculation composed of other fields and operators to combine the fields. The fields can come from the current entity or a related parent entity[2]. The calculations can be simple generic math operations, like additions or multiplications, or operations depending on the type of the field. The complete list of functions can be found in Microsoft documentation.
A calculation can also contain some logic with conditional operations, such as “greater than” or “if-else”.
These calculations are performed by the CRM and configured directly in Dynamics: no code is needed. In Dynamics, the calculation will be performed when a form is saved. The value will then update itself: no refresh of the browser is required.
Also, a formula can always be changed for a given field.
Be also aware of the following specificities of calculated fields:
- They can’t refer to themselves or have cyclic chains.
- They can't trigger workflows or plugins.
- They can’t trigger duplicate detection rules.
- They are not displayed in Outlook Offline mode.
- A max number of chained calculated fields is 5 (using a calculated field inside another calculated field inside another …, etc…).
- It can only span 2 entities: A calculated field can contain a field from another entity (so this would be touching 2 entities – current entity and parent record). However, a calculated field cannot contain a calculated field from another entity that also contains another field from a different entity (touching 3 entities).
Examples
Take-away points
- Easily configured – no code needed.
- Simple mathematical formulas,
- More complex formulas with pre-built operations.
- If-else behavior.
- Cannot trigger workflows, plugins nor duplicate detection rules.
Comments
Can we change simple attribute field type which is referenced
Hi,
You have placed a very useful article.
I have one question.
Can we change simple attribute field type which is referenced in "calculated" field?
for ex. Let simple field name is "X" and its behavior is Date & Time, now we create a new calculated field which has reference field "X". Now I want to change the behavior of the field "X" from Date time to Date Only.
Is it possible using SDK or using customization?
Thanks
Dear Patel, Thank you for…
Dear Patel,
Thank you for your message. Regarding your question, you can change the field but the calculation must still remain valid. For example, changing from DateTime to DateOnly should work, but not the other way around.
Both SDK or customization should do the trick.
I hope this helps! If you have any other questions or concerns, please don’t hesitate to ask.
Best regards,
Danny