Other Field Details Continued

In this step, with continue with Other Field Details.

Floating Point Number

Unlike Whole Number fields, Floating Point Number fields can contain a decimal point. However, floating point numbers are subject to rounding and are inexact.

The properties that are available for floating point number fields include the following:

• Precision – This is an option set that offers the numbers 0 to 5 and represents the number of digits that are displayed to the right side of the decimal point.
• Minimum Value – Specify the smallest acceptable value. The smallest possible value is -100,000,000,000.00.
• Maximum Value – Specify the greatest acceptable value. The greatest possible value is 100,000,000,000.00.

Decimal Number

A Decimal Number field can contain a decimal point. However, unlike a floating point number, the value is exact and not subject to rounding.

The properties that are available for decimal number fields include the following:

• Precision – This is an option set that offers the numbers 0 to 10 and represents the number of digits that are displayed to the right side of the decimal point.
• Minimum Value – Specify the smallest acceptable value. The smallest possible value is -100,000,000,000.00.
• Maximum Value – Specify the greatest acceptable value. The greatest possible value is 100,000,000,000.00.

Selecting Between Numeric Data Types

When you select the correct type of number field to use, the decision to use a whole number or currency type should be fairly clear. Deciding to use floating-point or decimal numbers requires more thought.

Decimal numbers are stored in the database exactly as they are specified. Floating-point numbers store a very close approximation of the value that is converted to a binary representation.

Use decimals when you must store and calculate values that require accurate answers, or where a small error could be magnified by later calculations that are performed (this includes aggregating the values from multiple records). If you expect to use queries that search for values that are equal or not equal to another value, use decimal as the field data type.

Use floating-point numbers when you store data that represent fractions or values that you typically query if you are comparing the fractions or values to another value by using greater than or less than operators. If you are performing many calculations with the fields, floating-point numbers might give a small performance gain compared to decimals.

Something else to consider would be if the values will be brought into the Power Platform from another system or database or extracted to another system through any kind of integration code or application. Storing the values in the Power Platform in the same format as the other application or database will improve performance of the integration code by avoiding the need to convert values back and forth between formats during the data integration process. This can be especially problematic if a value is copied from one system to another system, and then another value is calculated from the other system and brought back the other way (sometimes this is known as a ’round-trip’). Being converted both ways can compound the minor inaccuracies of floating-point representation into a much larger error, especially after many such round trips. In most cases, the difference between decimal and floating-point is not noticeable. Unless you must have the most accurate calculations or have integrations to other systems to consider for these fields, floating-point numbers should be a suitable selection for most scenarios.

Currency

A currency field contains a financial amount, such as the cost of a product, a salary, or the price of a ticket.

The first time that a currency field is added to an entity the Power Platform creates four fields. For example, if you add a custom field that is named Price, that has currency as the field type, the Power Platform creates the following fields:

Each additional currency field that is added creates only two fields – for example if a discount field is added discount and discount_base are added to the Power Platform. An additional currency lookup or exchange rate field is not created.

The properties of a currency field include the following:

• Precision – By default, this field has a setting of currency precision. This means that the field will store a value to the same number of decimal places as is set in the organisation’s currency settings. This can be overridden on each currency field by changing this value to a number between 0 and 4. Or, pricing decimal precision can be selected. This uses the value of the pricing decimal precision setting from the organisation’s system settings.
• Minimum Value – Enter the minimum permitted value for the field. The smallest possible value is -922,337,203,685,477.0000.
• Maximum Value – Enter the maximum permitted value for the field. The largest possible value is 922,337,203,685,477.0000.

Multiple Lines of Text

If you have to store a large amount of text, such as a description field, use a Multiple Lines of Text field.

The properties of a Multiple Lines of Text field include the following:

• Maximum Length – The maximum number of characters that can be entered in the field. This can be any number between 1 and 1,048,576.

Date and Time

In Dynamics 365 for Customer Engagement, the Date and Time data type is used in many system entity fields. For example, you can show when an account was last used in a marketing campaign or the date and time when a case was escalated. You can also create custom entities that include the date and time fields. Depending on what the field represents, you can choose several different field behaviors: User Local, Date Only or Time-Zone Independent.

• User Local – Date Only – or – Date and Time Format (In the user interface (UI), you can change certain out-of-the-box entity field’s behavior from the User Local to Date Only.)
• Date Only – Date Only Format (The Date Only behavior can’t be changed to other behavior types, once it’s set.)
• Time-Zone Independent – Date Only – or – Date and Time (The Time-Zone Independent behavior can’t be changed to other behavior types, once it’s set.)

Lookup

A Lookup field features a button that is clicked to display a list of records for the user to select a suitable related record. A lookup field represents a 1:N relationship.

The properties of a Lookup field are shown in the ‘Lookup Field Properties’ figure and include the following:

• Target Record Type – Select the record type that will be displayed when the lookup button is clicked.
• Relationship Name – Each Lookup field is associated with a N:1 relationship between the entity the field belongs to, and another, known as the primary entity in that relationship. A name for the relationship can be specified here when you create a Lookup field.

Image

Although you can add one image field to custom entities, you cannot add an image field to any system entity. When you create an image field, you can select the display name. However, the schema name is always set to entityimage (this does not use the prefix from the Solution Publisher). This fixed name prevents any entity from having more than one image field.

The image is shown on the form for a record by using a placeholder, if no image is saved for that record. By clicking the image, the user can change and upload the image that he or she wants to use. For example, this might be a picture of a person, a product, or a company logo.

Uploaded images must be 5,120 KB or less and in one of the following formats and file name extensions: jpg , jpeg , gif ,tif, tiff, bmp, png

All uploaded images are converted to .jpg format and resized to 144 × 144 pixels. You might have to show users how to crop and resize images before images are uploaded to improve the results.

The uploaded images are stored as records of the image entity, and the image field is effectively a lookup that stores the GUID to the record that is created by the upload.

Next up, let’s uncover Other Field Properties.