Difference between revisions of "Default Value"
imported>Aeric |
imported>Aeric |
||
Line 25: | Line 25: | ||
===Limitations=== | ===Limitations=== | ||
Default values cannot be applied: | Default values cannot be applied: | ||
*to [[Web Forms]] | :*to [[Web Forms]] | ||
*during [[Data Import]] | :*during [[Data Import]] | ||
*for fields which are not in the [[Form | :*for fields which are not in the [[Form]] | ||
==Available Field Display Types== | ==Available Field Display Types== |
Revision as of 22:51, 12 July 2011
When default values are defined for a field, data entry tasks take less time, because fields are automatically populated with correct information.
Default field values can be used to support these actions:
- Include a date/time stamp in a reservation record
- (use a timestamp to manage first-come, first-served request processing)
- Append a code prefix to a field value
- (create a code based on the request type or the originating territory/zip code/state - the code can be used in workflow decision-making)
- Automatically set the default fulfillment date for orders to be 'x' days from today
- (use the future fulfillment date to manage work)
- Create Dynamic Filters as default field values
How it Works
A Formula can be used to define a default value for a field. The formula is applied differently, depending on the situation - when a new record is added, or an existing record is edited.
New Record
- When a new record is added from the browser interface (when a user edits a form), the default value automatically appears in the field.
- If the record is saved with the default value in place, the default value is saved with the record
- If the user changes field value, the new value overrides the default value and is saved with the record
- If the user changes field value to <BLANK>, it overrides the default value and is saved with the record
Existing Record
- When an existing record is edited, the default value appears as it was when last saved.
- If a default value was saved as <BLANK>, the default value automatically appears in the field
Limitations
Default values cannot be applied:
- to Web Forms
- during Data Import
- for fields which are not in the Form
Available Field Display Types
For a list of available field display types, see: Field Display Types. A field can also default to an Expression based on Formula Functions, or can be built around a Dynamic Filter.
Add a Default Value to a Field
To set a Date Field to default as the current date:
- Add a new field
- Select Date Time as the Display Type:
- Add this expression in the Default Field area:
- NOW()
- Make any additional changes and [Save]
- A validation is performed to verify that the formula has the correct syntax
- To perform this validation, click the [Check Syntax] button; An error message will appear if the syntax is not correct
- When a new field is added, the Date Field you created will appear with an automatic timestamp:
To set a Date Field to default as 7 days from today:
- Add a new field
- Select Date as the Display Type:
- Add this expression in the Default Field area:
- DATEADD(TODAY(), 7)
- Make any additional changes and [Save]
- A validation is performed to verify that the formula has the correct syntax
- To perform this validation, click the [Check Syntax] button; An error message will appear if the syntax is not correct
Examples
Expression | Field Display Type | Description |
---|---|---|
if( user.firstname = 'Jim','A,B','C') | Multiple Check Boxes | Set the default checkbox value, based on an expression.
In this example, assume that the values in a multiple check box are A, B and C. This expression assigns the following checkbox values, based on whether the user first name is Jim: If the user.firstname field is equal to 'Jim', checkboxes A and B are checked If the user.firstname is not equal to 'Jim', box C is checked |
DATEADD(TODAY(), 7) | Date | Set the field default to 7 days from today (next week) |
Dynamic Filters
Dynamic Filters define a query with field variables, enabling more powerful controls.
- Use Dynamic Filters when complex associations are needed for Record Selection Criteria
- How it Works
-
- In a Technology Asset record, display a list of Technicians certified to support or repair the equipment
- For an Inventory Application, add a field to a Part Record that finds only component parts (subcomponents of the Part)
- For a Product or Service Ordering Application, add a field to a Brand Record that limits the lookup to products that belong to the brand family
- In a Candy Manufacturing Application, add a field to a Recipe Record that identifies organic ingredients only
- Guidelines for building Dynamic Filters
- The format of a Dynamic Filter changes, depending on the type of field:
- Lookup
- Other (text, date, other alphanumeric field)
- To specify Dynamic filters in the UI, insert a derived field name in the Value field of the Record Selection Criteria builder
- To create a derived field name, include a dollar sign ($) before the internal field name (this identifies the value as a dynamic filter)
- If a Lookup field is chosen, use the $fieldname_name format
- For all other fields, use $fieldname
- Where fieldname can be found in Field Name
- Examples
-
- In a Lookup field of Object "Employee", to restrict the Employees available depending on the Location, set filter to {0} in the Location field. If the Location is any other field type, set filter to {1} in the Location field.
- An IT assets object is linked to the Service Techs object, which includes staff members who are responsible for support
- Service Techs have an Area of Responsibility that matches one of the available IT asset Types: "Laptop", "Desktop", or "Server"
- The Service Tech object is defined as follows:
- In the IT asset object, the Lookup field to the Service Tech object includes Record Selection Criteria that limits the lookup to Service Techs with Areas of Expertise that match the Asset Type:
- When assigning the asset to a user, a Service Tech is selected, and the list of Service Techs displayed in the Lookup Window shows only the techs with expertise in the required area of technology
- User-specific template variables
- Record data can be compared to the User object data for the current user. Those criteria have the form:
- {field_name} {operator} $user.{User_object_field}
- For example:
- Owner equals $user.id - Records owned by the current user
- Created By equals $user.id - Records created by the current user
- Modified By equals $user.id - Records modified by the current user
- City equals $user.city - Records in the current user's city
- Similarly, were you to add a custom hiredate field or birthday field to the User object, you select records that came before or after that date using the less than and greater than operators.
Label Template Variable Comment Current Date $today Current date in Company date format Current Date User Date Format $today_dateformatted Current date in User's date format User Id $user.id User Full Name $user.fullname First name and last name, together User First Name $user.firstname User Last Name $user.lastname User Email Address $user.email City $user.city State/Province $user.state Zip/Postal Code $user.zip Country $user.country Title $user.title Division $user.division Phone $user.phone Fax $user.fax Mobile Phone $user.mobile Street $user.street User HTML Signature $user.html_signature User Text Signature $user.text_signature User Name $user.username User's login name All custom fields defined on the User Object