Visibility Conditions

Overview

The Visibility Condition section of Custom Fields, UTA Standard Fields, Contact and Account Standard Fields and Submit Buttons enables the application of logical statements to ascertain the visibility of a field. Visibility is commonly determined through conditions based on roles, types, statuses, and even specific field values.

Note: Visibility Conditions are enforced upon page loading and do not operate dynamically if the condition relies on altering the value of a field present on the page. For dynamic visibility adjustments, it is recommended to utilize the Show/Hide Header procedure.

Basic Condition Syntax

Visibility is determined by evaluating the truth of a specified condition. For instance, if a field is intended to display solely for individuals in the Reviewer role, the condition syntax would be structured as follows:

@me.inRole(Reviewer)@

If the condition holds true—that is, if the user accessing the page possesses the Reviewer role—the field will be rendered visible.

Conversely, a negative condition can also be established: the field is to remain hidden from a Reviewer.

!@me.inRole(Reviewer)@

Note: As the statement must be true, the aforementioned syntax effectively seeks to display the field to any user not holding the Reviewer role.

Additional Examples

"@status@" in ('Draft','Open')

"@fieldname.length@"*1>0

"@Type@"!="Contract"

"@date(currentdate)@">"2015-02-06"

"@fullstartdate@" >= "2009-05-01"

"@Date Initiated@" >= "2014-01-31"

• IMPORTANT: For a visibility condition based on the startdate or enddate:

• Utilize '@fullstartdate@' instead of '@startdate@'
• Utilize '@fullenddate@' instead of '@enddate@'.

* This will format the stored date as yyyy-mm-dd, enabling comparison using < and >.

"@fullstartdate@" >= "2009-05-01"

Multiple Conditions

It is also feasible to evaluate multiple conditions:

• For an OR condition, use two pipes (|)

"@status@" = "Closed" || "@me.fullname@"="Jane Doe"

The above field will be visible if either the status of the record is Closed, OR if the user accessing the record is named John Doe.

• For an AND condition, use two ampersands (&)

"@status@" = "Closed" && "@me.fullname@"="John Doe"

The above field will be visible only if the status of the record is Closed AND the user accessing the record is named John Doe.

• A combination of these can also be executed, employing brackets to dictate the order of evaluation:

( "@status@" = "Closed" || "@status@" = "Cancelled") && ("@me.fullname@"="John Doe" || "@me.fullname@"="John Deer" || "@me.fullname@"="Dear John")

The above field will be visible only if the status of the record is either Closed OR Cancelled, AND the user is one of the three specified individuals.

• True if the Level 1 status is 'Draft':

'@opportunity.status@'='Draft' 

or

'@opportunity.status@' In ('Draft')

• True unless the Level 1 status is 'Draft' or 'Open':

'@opportunity.status@' Not In ('Draft','Open') 

• For a visibility permission based on the startdate or enddate standard fields:

'@fullstartdate@' >= '2009-05-01'

• Utilize '@fullstartdate@' instead of '@startdate@' and '@fullenddate@' instead of '@enddate@'.

• This will format the stored date as yyyy-mm-dd, allowing it to be compared using < and >.

• True if today's date is after the Start Date:

now()>'@fullstartdate@'

• Never True

1=0 

or

false

• Always True

1=1

or

true

Note

• It is generally advisable to enclose variables in double quotes (") rather than single quotes ('). This is due to the fact that single quotes can also serve as apostrophes; therefore, if the variable is processed and substituted with a term containing an apostrophe, it may prematurely terminate the statement and result in a server-side error. In principle, the variable could also be replaced with text containing a double quote, potentially leading to an error, but double quotes are less frequently stored.