Searching for content

Overview

Adobe Acrobat Sign allows for complex searching to find content in the user's agreements. The search bar, found on the Manage page, returns all transactions that match any string provided for the content source selected.

  • If you are looking at "your agreements", you search against your content. If you are looking at a shared account, you search that shared accounts' content

The content in the below fields is indexed as a transaction is created/updated:

  • Title - Agreement title.
  • Note - A private agreement note taken by the participant that is not visible to anyone else.
  • Message - A list of messages visible to this participant (includes both public and private messages.
  • Original File Name - Original name of an uploaded file associated with the agreement.
  • Email - Recipient (including CCs) or sender’s email address.
  • Full Name – First and last name of the recipient (including CCs) or sender.
  • Job Title – Job title of the recipient (including CCs) or sender within their company.
  • Company Name – Company or organization name of the recipient (including CCs) or sender.
  • Recipient Group Name – Name of the ad-hoc agreement group name that recipients can belong to.
  • Text Field Content - User-provided text field content in the form.
  • Sharer's Full Name  - Full name of the sharer of the agreement. In a non-sharing case, this is the name of the user.
  • Sharer‘s Recipient Group Name - Recipient group name of the sharer of the agreement. In non-sharing case this is the recipient group name of the user.
  • External ID - Sender assigned ID to the agreement that can be of any form, but usually in form of "<groupID>:<ID>". External ID is passed in the call to the agreement creation API.
  • External Group ID - Sender assigned group ID to the agreement that can be of any form, usually used as a prefix for external ID. External Group ID is passed in the call to the agreement creation API. You are required to set External ID if setting External Group ID parameter.

How text searching works

If you were searching for the string: "A simple fish"

  • Acrobat Sign "tokenizes" the string, using spaces as delimiters. The above example string is broken into three tokens: Asimple, and fish
    • Characters in string query belong to one of three different types: letter, number, or delimiter.
    • Characters treated as delimiters (other than whitespace) are: ~ ` ! @ # $ % ^ & * ( ) - + = { } [ ] | \ . , : ; " ' < > ? /
      • Periods, underscores, and apostrophes remain as part of a token if characters before and after that symbol are of the same type.
      • Quotes that surround the whole query string are not delimiters and specify a literal string value (phrase)
      • Quotes inside a query string are delimiters and do not specify a literal string value
  • Case distinction is removed. eg: a, simple, and fish
  • Search then tries to match the full text of each token to an indexed value
    • More complex tokenization occurs for the Agreement Title (see below)
  • An inclusive search is used,  meaning that every agreement that matches at least one token from at least one searchable field is included in the returned dataset
    • The returned dataset is sorted by relevance score with the most relevant search result being at the top.

The Agreement Title field:

As noted above, the Agreement Title field has more sophisticated tokenization due to an additional "customized" tokenizer that primarily tokenizes on context delimiters (vs. explicit characters). This custom tokenizer is different from the standard in that:

  • Prefix tokens (up to 10 characters) are generated - A prefix token is the incrementing string of any standard token. eg: If the standard token is fish, the incrementing tokens are: ffifis, and fish
    • This allows searching for partial strings, given you start at with the first character of the token
    • Mid-string matches are ignored. eg: Searching for rent will not match the word apparently
  • Split tokens at non-alphanumeric characters. eg: The string: Super_Duper yields the tokens: Super and Duper
    • Underscores are not delimiters in the standard tokenizer
  • Split tokens at letter case transitions. eg: The string: PowerShot yields the tokens: Power and Shot
  • Split tokens at letter-number transitions. eg: The string XL500 yields the tokens: XL and 500
  • Removes leading or trailing delimiters from each token. eg: The string: XL---42+'Autocoder' yields the tokens:  XL42, and Autocoder
  • Removes the English possessive ('s) from the end of each token. eg: The string: Dave's yields the token: Dave

Note that the combination of the standard and custom tokenizers allows you to search for the full token string (thanks to the standard tokenizer) and the prefix tokens (thanks to the custom tokenizer), but you will not match a prefix token that spans a delimiter. 

Example 1:  If you have an agreement named My_NDA

  • The standard tokenizer would produce a token that looked like: my_nda
  • The custom tokenizer would produce a series of prefix tokens: mmynnd, and nda
  • Attempting to search for my_nd would return no results because 
    • The standard tokenizer does not create prefix tokens, only full strings
    • The custom tokenizer delimits the underscore, so any prefix tokens would not include it

Example 2: If you have an agreement named XL500

  • The standard tokenizer would produce a token that looked like: xl500
  • The custom tokenizer would produce a series of prefix tokens: xxl550, and 500
  • Attempting to search for xl5 would return no results because 
    • The standard tokenizer does not create prefix tokens, only full strings
    • The custom tokenizer delimits the letter-number transition, so no prefix token can be created that bridges from a letter to a number

Searching with special query syntax

As described in the section above, Agreement Search performs an approximate match among all searchable fields of an agreement. Searchable field content is tokenized, and then those tokens are matched to the query string at query time. Agreement Search also performs a prefix match up to 10 characters for those tokens. However, matches of an entire field value and matches of a phrase from a field value can be achieved only with a special syntax.

PHRASE MATCH QUERY:

A phrase match query should be used when a phrase search among all searchable fields is required.

  • A regular approximate match query will match if ANY of the tokens appear in a field (but not necessarily all), and the token order is irrelevant since tokens don't need to appear together
  • phrase match gives us the ability to match where multiple tokens appear in the same field, and those tokens appear in the order specified within the quotes

Phrase match query syntax format:

'<phrase_match_query>'

or

"<phrase_match_query>"

If the query syntax doesn't follow the rules for a phrase match query syntax, Agreement Search will perform a regular approximate match query among all searchable fields.

FIELD NAME PREFIX QUERY:

A field name prefix query should be used when searching for only one particular field of user's agreements. The field name prefix query should contain a field name prefix followed by a regular approximate match or a phrase match query.

Field name prefix query syntax format:

<field_name>:<query>

or

<field_name>:"<phrase_match_query>"

or

<field_name>:'<phrase_match_query>'

If <field_name> is not specified, all fields supported for the phrase match will be queried. Otherwise, only the <field_name> field is queried. 

If the query syntax doesn't follow the rules for the field name prefix query syntax, Agreement Search will use the whole query as a search query (approximate match or phrase match, depending on the syntax) and perform a search among all searchable fields. 

For example, phrase match query:

title: "Hello World"

should perform a search only against the field that contains the title of the agreement.

Below is a list of prefixes supported for the field name prefix query.

Field name prefixes are case-insensitive.

FIELD CONTENT

 STRING QUERY FIELD NAME PREFIX

FIELD CONTENT DESCRIPTION

Title

title*

Agreement title.

Note

note

A private agreement note taken by the participant that is not visible to anyone else.

Message

message

A list of messages visible to this participant (includes both public and private messages.

Original File Name

originalFileName

Original name of an uploaded file associated with the agreement.

Email

email**

Recipient (including CCs) or sender’s email address.

Full Name

fullName***

First and last name of the recipient (including CCs) or sender.

Job Title

jobTitle

Job title of the recipient (including CCs) or sender within their company.

Company Name

companyName

Company or organization name of the  recipient (including CCs) or sender.

Recipient Group Name

recipientGroupName

Name of the ad-hoc agreement group name that recipients can belong to.

Text Field Content

textFieldContent

User-provided text field content in the form.

Sharer's Full Name sharerFullName Full name of the sharer of the agreement. In non-sharing case this is the name of the user.
Sharer's Recipient Group Name sharerRecipientGroupName Recipient group name of the sharer of the agreement. In non-sharing case this is the recipient group name of the user.
External ID

externalId

Sender assigned ID to the agreement that can be of any form, but usually in form of "<groupID>:<ID>". External ID is passed in the call to the agreement creation API.

External Group ID

externalGroupId

Sender assigned group ID to the agreement that can be of any form, usually used as a prefix for external ID. External Group ID is passed in the call to the agreement creation API.

You are required to set External ID if setting External Group ID parameter.

For backwards compatibility, some of the field name prefixes have aliases which are equivalent in functionality to the original field name prefixes. Those aliases are deprecated and will be eventually removed:

  *  Field name prefix 'name' can be used instead of 'title'.

 ** Field name prefix 'participantEmail' can be used instead of 'email'.  

*** Field name prefix 'participantName' can be used instead of 'fullName'.

Filtering the returned data

Searching your content can return a daunting number of records.

Four filters, which can be used individually or in combination, are available to help reduce the dataset to a manageable listing of records.

Filtering by Modified Date

The Modified Date value filters the most recent time/date stamp when a user action updates the agreement. The Modified Date becomes a locked value once the agreement reaches a terminal status (Complete/Canceled/Expired).

The Modified Date filter icon opens the options to reduce further the data set by selecting a date range:

  • All dates
  • Last 24 hours
  • Last seven days
  • Last 30 days
  • Last 12 months
  • Custom date range

Filtering  by Field values

Using the Search input box (to the right of the Filters button), you can apply a filter to individual fields that can hold highly specific or unique data.

The searchable field options are:

  • All fields - The default value; this option searches all field options for the exact string in the Search field, returning the largest set of records.
  • Title - Limits the returned dataset to records with the searched string found in the object's title (e.g., Agreement name).
  • Note - Limits the dataset to records that contain the searched string in the searching user's personal notes.
  • Message - Limits the dataset to records that contain the searched string in the Message field or Private Message of the agreement.
  • Original file names - Evaluates the file name of the original uploaded document and returns only records that match.
  • Email - Matches the email address of a recipient.
    • Note that this filter does not trap Text fields defined with an Email Address validation.  
  • Full name - Matches the Name value supplied by a recipient when applying a signature. If only one name is provided, all records that match that one value are returned.
    • Note that Name values depend on what the recipient enters and may not match previous signature values or profile names (if the recipient has an Acrobat Sign user account).
  • Job title - Matches values placed in the Title field.
  • Company name - Matches values placed in the Company field.
  • Recipient group name - Matches the (sender entered) Recipient group name.
  • Text field content - Matches the exact value of any Text input field. This includes default values and individual words found in larger text blocks.

Filtering by Group

Accounts with Users in Multiple Groups enabled have access to a Group filter that limits the returned dataset to only agreements sent from that group.

Search filters

Filtering for hidden content

An additional option to Search hidden content is available.

When the Search hidden content is selected, only hidden content is included in the returned data set

Note:

When a filter is selected, a tag is displayed next to the filter icon.  Any one filter can be clicked to remove it after the data set has returned.

 Adobe

Get help faster and easier

New user?