Home > Articles > Data > FileMaker

This chapter is from the book

This chapter is from the book

Assigning Field Options

In addition to establishing fields and assigning data types, you may assign options to your fields as well. These range in function from managing auto-entry of default data to validation checks and internal storage settings. They can vary for each field type.

After you have named a field and chosen its type on the Fields tab of the Define Database dialog box, click Create to save it to your database. You may then opt to apply further behaviors via the Options button on the right. The first set of options is the auto-entry behaviors.

Auto-Entry Field Options

When defining non-calculation fields in FileMaker Pro, you can choose to apply a range of options as records are created and/or modified. The applications for this can range from assigning default values to fields, to automatically reformatting data, or inserting values from other fields based on certain "trigger" events.

In some cases you might not even allow users to modify these auto-generated values, such as when tracking a serial ID or applying a date you don't want adjusted afterward (see Figure 3.4).

Figure 3.4Figure 3.4 Auto-entry of data allows you to define rules for automatically populating data into fields in your database.

Auto-entry data is inserted into a field based on some trigger event. The most common event is record creation: When a user clicks New Record, data can be pre-populated into the record and then be accessible for changes to be made. Each Auto-Entry function has its own particular rules for what trigger event applies.

In addition to new record creation, other trigger events include record modification and modification of a particular field.

Creation and Modification

The first two options on the Auto-Entry tab deal with tracking and applying certain values as a record is committed to your database. They behave essentially the same way, with Creation values being applied the first time a record is committed, and Modification values applied thereafter as it is subsequently modified (committed again).

Values you can opt to apply comprise the Date, Time, Timestamp, Name (from the General Preferences dialog under the Edit menu), or Account Name (that which the user validated during login.)


Name is something users can modify as they will via the Preferences dialog, so you generally shouldn't depend on it for anything vital. If you want to depend on knowing who has created or modified a given record using auto-entry functions, always use the Account Name option.


If you do not change any of the account settings of a new file, FileMaker will have established two default accounts for you: Guest and Admin. Both begin with full access to the database.

Serial Number

Here you're able to set a number that increments every time a new record is added to the table. Often this is used to uniquely identify individual records in a table. The value can be generated either when the record is created or when it is committed. The difference is subtle: In the case of incrementing on creation, your number increments even if a user then reverts and effectively cancels a record's creation. The next record will then have "skipped" a number in your sequence. This doesn't have much of an effect on your database unless your business requires strict tracking of each serial number, even those voided. In those cases, choosing On Commit helps avoid spaces in the sequence.

It is possible to include text characters in addition to a number as the starting value if you wish. This enables you to create serial numbers that look something like "a1, a2, a3, a4..." Only the numeric portion of the value is incremented; the text portion remains unchanged.

One of the common uses of auto-entry options is in establishing serialized key values, or IDs. This is a vital element of your database structure when working with more than one table, but regardless of how complex or simple your plans are, we encourage you to adopt some best practices.

For every table in your database, the first field you should create is a "primary key" or ID field. It is these IDs that uniquely identify each record in your database. There are several ways one could go about having the system establish unique IDs automatically; our recommendation in most cases is to use a serial number set to increment automatically.

We can't stress this practice strongly enough. If you ever want to tackle relational data structures, these serial IDs are a vital element in doing so. Further, if you ever export your data to another system or need to interact with other databases, having a key field that uniquely identifies each record in your database will make keeping track of your data possible.

To create a serial key field, use the following steps:

  1. Define a number field. (It is generally advisable to use number-based serial keys, but it is possible to use text as well; the important thing is to make certain your keys are unique and un-modifiable.)

  2. Go into the Options for that field and select the Serial Number option.

  3. Click the Prohibit Modification of Value During Data Entry option at the bottom of the dialog. This is an important step: If you establish unique identifiers that your users can then override, you're risking the chance that they'll introduce duplicate IDs.

If you need an ID field for a business purpose (SKUs, Student IDs, Employee IDs from your organization, and so on) we recommend that you create separate fields for such cases. Generally, users should never need to access this serialized ID field, but you may opt to put it on a layout and allow entry in Find mode so that they may search if they choose.

For a full discussion of the use of keys (or match fields), see the discussion in "Working with Keys and Match Fields."

Value from Last Visited Record

Used most often as a way to speed data entry when information is often repeated for groups of records, this function copies the value from a prior record into a given new record. Bear in mind: "Visited" means the last record in which you entered data. If you enter data in a record, then view a second record without clicking into a field and activating it, it is the data from the first, edited record from which a new record obtains its value.


Here you may specify literal text for auto-entry. This is frequently used to set default states for field entry. For instance, in an Invoice table, you might have a text field called Status where you want to enter "Not Paid" as a default. Being a regular text field, the value is fully modifiable by a user.

Calculated Value

In addition to establishing a field as a calculation field, where its value will always be controlled by its defined formula, it is possible to insert the results of a calculation into any other field—including a container field—as an auto-entry option.

Further, if you uncheck the, Do Not Replace the Existing Value For Field (If Any) option, the results of the calculation formula are entered into the field (overriding any existing value) any time a field reference by the calculation changes.

In other words, a referenced field in your calculation statement acts as a trigger—including the auto-entry field itself. This enables you to apply calculations to data entry on the fly. One great example of this is a phone number field. You may always want phone numbers formatted as "(123) 456-7890" regardless of how a user entered the data. By using this triggered auto-entry function, you can apply the results of a calculation whenever a field is modified.

For an example of this technique, refer to Figure 3.5.

Figure 3.5Figure 3.5 By using a self- referencing calculation, FileMaker Pro is able to replace and correct data as it is entered by the user.

The actual calculation for this Auto-Fill option looks like this (returned as text):

Let ( 
  //define variables:

rawNumber = Filter (Phone_Number; "0123456789") ;
length = Length (rawNumber);
red = RGB (160;0;0);

  //set error flag for a phone number that's too short
error = If ( length < 10 ; TextColor ("error: " & Phone_Number; red); "")

  // now apply the phone formatting and return results

  If ( error ≠ ""; error; 

    "(" & Left (rawNumber; 3) & ") " & Middle (rawNumber; 4; 3) &
    "-" & Middle (rawNumber; 7; 4) &

    // this condition tests for extra digits
    // that we'll treat as an extension
    If ( length > 10; " x" & Middle (rawNumber; 11; length - 10); "")


To learn more about advanced calculation functions, see Chapter 14, "Specialized Calculation Functions."

Looked-Up Value

This auto-entry option copies a value from a related record into a field. Any time the field controlling your association to that related record changes, FileMaker Pro updates the value in the lookup field.

For example, if a user enters a ZIP code into a given record, it's possible you could have another table then auto-populate your city and state fields with the appropriate information.

When a user enters a ZIP code in the highlighted field in Figure 3.6, the city and state fields below are triggers to pull values from the ZipCodes table. An important fact to keep in mind is that FileMaker has copied the values from the ZipCodes table. If the source data changes or is deleted, this record remains unmodified until it is re-triggered by someone editing the ZIP code field again.

Figure 3.6Figure 3.6 Lookup functions work somewhat like relational data, but instead of displaying values from a related record, their information is copied and stored when a trigger event occurs.

Take special note that lookup auto-entry functions work just as all auto-entry functions do: They copy or insert information into a field. You are not displaying related information, nor are you controlling content by calculation. Thus lookup values are not live links to related data: If you were to delete the records in the ZipCode table in the previous example, all your people records would remain untouched, preserving your city and state data.

This is an important distinction to understand, especially as we get into indexing later in this chapter.

To see how to create a lookup field, refer to Figure 3.7.

Remember that anytime your match field changes, your lookup refreshes. In this case, the auto-entry function does not act on record creation, but rather on committing/triggering.

When performing a lookup, it is possible to apply close matches. In the case of the ZIP codes example, obviously you'd only want an exact match or you might end up with incorrect data. In a different case, however, you need not be so strict. Consider a scheduling system that automatically finds the closest available appointment: Enter a target date into a field, and the lookup function could return the closest match. Another application might be a parts database with units of measurement. You may not be able to find a .78" wrench, but a .75" might work.

Figure 3.7Figure 3.7 Often you'll want only exact matches, but in some cases you can use the closest value based on a comparison of the trigger values in your related table.

How you set up your trigger values is important here. It's easy to compare numbers and come up with the next closest value. If your trigger field is text, FileMaker Pro uses ASCII value rules to compare and determine order.

For further discussion of lookups, see Chapter 6, "Working with Multiple Tables."

Housekeeping Creation and Modification Fields

As a best practice, we also recommend that you create another set of fields in all tables that help track changes. Create a timestamp field and in the Auto-Enter options, choose Creation Timestamp. Define another for Modification Timestamp, and text fields for Creation and Modification Account Names.

These four fields tell you exactly when a record was created or modified and by whom (assuming you assign an account to each individual person using your database). If you ever need to identify problem records for a given day range, time, or account, these fields allow such. We strongly recommend you add them every time you create a new table.

The only downside to following this practice is that additional storage space is required for this data, and in this version of FileMaker Pro, only in the most extreme case is that an issue.

Field Validation

Storing correct and complete information is critical for generating accurate reports, establishing proper, expected conditions on which other functions and calculations are performed, and ensuring overall data integrity. Unfortunately, most data applications suffer from a chronic condition of having humans interacting with them; although some humans are worse than others (like developers), none are perfect. We all make mistakes.

As data is entered into FileMaker Pro, you may opt to apply one or more validation checks to test that certain conditions are met before allowing users to commit the record to your system. This can be as simple as ensuring that a field isn't empty, or as complex as making sure that an invoice total doesn't contain multiple entries for the same product.

To review the various validation options available, see Figure 3.8.

Figure 3.8Figure 3.8 These are common validation settings for a numeric key value meant to always remain unique and unmodified by users. Even if your users can't access a given field on any layout, it's still a good policy to validate.

This example demonstrates a common approach to ensuring that your primary keys are properly maintained. This may be overkill if you've enabled the Prohibit Modification of the Value During Data Entry option on the Auto-Entry tab, but on the chance that a developer turns that option off for some reason, or that users import records into your database, this is a handy bit of insurance.

Importing records can circumvent your carefully designed field validation rules. For a full discussion, see Chapter 19, "Importing Data into FileMaker Pro."

Validation Conditions and Failure

Field Validation simply tests whether one or more conditions, as defined in your Validation dialog, is false. In the case where all tests are true, the user is not interrupted or prompted for action.

Figure 3.9 shows an example of what your users will see in cases where validation fails.

Figure 3.9Figure 3.9 The Yes option appears only in cases where a user has the option to override the validation warning.

In this case, the check box allowing users to override has been left enabled, so they do have the option to ignore the warning. When that function is disabled, the field does not allow "bad" data to be committed and the system forces users to deal with the problem. They can choose either to revert the field to its previous state or to clear it.

When Validation Occurs

Validation occurs when users enter data manually into the field being validated and then commit the record. Remember, however, that's not the only way to get information into a field. You can also import records or use various script steps, such as Set Field().

Validation isn't triggered simply by clicking or tabbing into a field; a change needs to be attempted. And keep in mind: Validation does not apply in cases where users modify other fields of a given record. A new value must be attempted in a given, respective field for that field's validation check to be performed.

At the top of the validation dialog (see Figure 3.8), notice the Always versus Only During Data Entry choices. The latter tests for the validation conditions when users modify the field in question. When the Always option is enabled, validation occurs during scripts and imports as well as during data entry.

If an import process attempts to write invalid data to a field, FileMaker Pro simply ignores the improper entry. The field remains unchanged and your data is not imported. You will see a note in the Import Records Summary dialog listing how many errors were encountered.

In the case where the Only During Data Entry option is used, that improper data would be inserted into your database.

If you get trapped in a series of validation dialogs, refer to "Validation Traps" in the Troubleshooting section at the end of this chapter.

Storage and Indexing

Field storage and indexing is found on the Storage tab in your Field Options dialog and deals with how FileMaker Pro manages the contents of your data internally.

Global Storage

A developer can designate a field to have global storage on the Storage tab of the Field Options dialog. Commonly fields with this option are simply referred to as "global fields" and collectively they're usually referred to as "globals." Global fields live independently from any specific record in the database and hold one value per user-session.

Global fields are often used by developers to establish variables during scripts, to display programmatic field labels (as opposed to simply leaving text on a layout), or to maintain system preferences. Globals have a wide range of applications.

One vital element to learn is when data is committed and stored for globals: In a single-user environment, any change to a global field is permanent and is saved across sessions. In the case of a multi-user environment—where a FileMaker Pro solution is hosted on FileMaker Server or via multi-user hosting—global values for each guest default to the value from the last time the database was in single-user mode; any change made to these defaults will then be specific only to a given user's session. Other users continue to see the default values, and after the database session is closed it reverts to its original, default state.

Using globals is a great way to keep track of certain states of your database. For example, you could use a global field to store which row of a portal was last selected. This field could then be used in scripts or calculation formulas.

For an example of using a global to drive portal behaviors, see "Selection Portals."

Another common use of globals is for storing system graphics. Establish a container field, set it for global storage, and paste a favorite company logo, a custom button graphic, or any number of elements that you can then control globally in a field rather than having to paste discrete elements on each and every layout.

A third use for globals takes advantage of their being user-session specific. A developer can set a global with user account information and refer to such via scripts, confidant that the same script will work for each individual user of the system. Person A's global field relates to him or her, and Person B's field holds his or her relative data.

Repeating Fields

The second section of the Storage tab on the Field Options dialog lets developers allow a field to contain multiple values. Such fields are known as repeating fields. On a given layout the developer can array repetitions either horizontally or vertically, and in scripts can refer to specific repetitions within the field.

Repeating fields can be problematic. They behave just as individual fields might and are really just a shortcut for having to define multiple instances of a given type of field. It's possible, for example, to have no values in the first and second repetitions, but to have a value in the third. This sounds convenient and intuitively makes common sense, but imagine having to write a script that references that field. How do you know which repetition of the field to reference? Unlike an array in other programming languages, a repeating field cannot be manipulated as a whole. You can reference only one specific repetition at a time.

Repeating fields do have their place, however. Imagine a spreadsheet. Even though an entire row may be blank, the cells are there, ready and waiting for input. If your users are familiar with Microsoft Excel or have been using a paper form for years, it may make sense for you to duplicate the look-and-feel in question, using repeating fields.

In addition to facilitating data entry, one could simulate a related child table with repeating fields.

For a detailed discussion of multiple-table solutions, see Chapter 6, "Working with Multiple Tables."


Databases store data by definition, of course, but they are also required to perform functions such as searches and sorts with that data. FileMaker Pro, like many databases, can index some of the data in a file to increase the speed at which it performs some of these functions and to enable it to relate data across tables.

An index is somewhat like a database within a database. FileMaker Pro can store, along with a specific value in a given field, all the records in which that exact data is used. This then enables FileMaker to recall those records quickly without having to resort to a linear scan of your file. Aptly named, these indexes work just as a book index works: They facilitate finding all the locations in which a given item is used.

To familiarize yourself with the concept, take a look at a given field's index. Click into a field and select Insert, From Index. If the field is indexable, and has already been indexed, you are presented with a dialog box showing all the discrete values indexed for a given field. Just as with selecting from a value list, you may opt to choose from this list rather than type.

Allowing a user to select from an index is only one of the reasons for having them. Indexes enable FileMaker Pro to perform find requests, sort records, and establish relationships.

New in this version of FileMaker are two kinds of indexes: value indexes and word indexes. Value indexes apply to all field types, with the exception of container or summary fields; word indexes only apply to text fields and are based on a given language or character set. The difference between the two, and when either is specifically enabled, lies in their applications.

FileMaker Pro's default setting (found on the Storage tab of the Field Options dialog, displayed in Figure 3.10) is None, with the check box for Automatically Create Indexes As Needed enabled. Most developers, even the more advanced, should find that this setting serves their needs.

Value indexes are established by a database's schema definition—as a developer defines fields and builds relationships—and allow for relationship matches and value lists. If a developer creates a serial ID and joins a relationship via such a field, a value index is created for the serial ID field.

Unless a developer explicitly sets a field to generate one, Word indexes are created as users are interacting with and using a given database. They are utilized for find requests, or created when a user explicitly chooses Insert, From Index. If a user enters data in a find request for a field that lacks a word index, FileMaker Pro enables indexing for that field and builds one (unless its explicitly unindexed, or an unindexable calculation).

Figure 3.10Figure 3.10 FileMaker creates either one type of index or both, depending on how a field is defined and used by users.

At this point you may be wondering what all the fuss is about. Why not index every field in a database and be done with it? The downside to indexes is increased file size and the time it takes FileMaker to maintain the indexes. Creating new records, deleting, importing, and modifying them all take more time, in addition to the fact that the indexes themselves take up more file space.

Notice that FileMaker doesn't allow you to explicitly control word and value indices. Value indices are possible for all field types: Word indices apply only to text fields. Minimal prevents a word index from being created—thus forcing any find requests to be processed through unindexed fields.

Only a subset of the fields in your database will ever need to be indexed, and FileMaker's "on demand" approach makes things fairly simple for developers. Generally speaking, it's best if a field is indexed only when necessary.

To explore the vagaries of storage and indexing considerations for calculation fields, see "Other Options."

An important point to remember is that some fields are not indexable. This means than they will be slow when used in sorts and find requests, but most importantly they cannot be used to establish relationships.

A field is unindexable if it is a calculation based on a related field, a summary field, or a global field, or if it references another unindexed, unstored calculation field.


The fourth tab in the Field Options dialog is one that many English-speaking developers will have trouble properly pronouncing, let alone using. Because of the adoption of Unicode support in FileMaker Pro 7, it is now possible to offer Asian-language double-byte language support. As a result, you can now manage Japanese.

Japanese has four alphabets. One is based on glyphs from Chinese, known as Kanji, two are based on phonetic syllables known as Hiragana and Katakana, and the last is our own Roman alphabet, adopted in the 19th century for foreign words. When working in Japanese, it is possible to render the phonetic equivalents to a Kanji-based block of text. Quite useful when one doesn't quite know how to read one of the 20,000+ characters in Kanji.

Suffice it to say that unless you're a student of Japanese (native or otherwise), this tab will likely not attract much of your attention.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020