Using Search in IdentityNow

Search allows you to create flexible inquiries that help you gain insight into all your data, and the power to manage your identities. Search allows you to find specific identities, entitlements, and other data that match criteria you enter. You can download reports of your search results, or create governance policies out of them.

 

Take a look at our documentation map for an overview of the documentation surrounding Search.

 

Learn the Basics Build a Search Query More Information Downloading Reports

Overview of Search

In this document, you can:

  • Take a tour of the main Search page
  • Learn Search terminology
  • Find examples of searches
  • Explore more Search pages

 You are here!

In this document, you can:

  • Learn about the fields you can search on
  • See how to put them together into a query

Learning More About Search

In this document, you can:

  • See frequently asked questions
  • Learn about IdentityNow's data model
  • Find additional Search information

Downloading Reports from the Search Interface

In this document, you can:

  • Learn about downloading default and custom reports from Search
  • Find out how to interpret those reports

 

Elements of a Search

The organization of your data within IdentityNow is called the data model, and understanding this data model can help you create the most effective search queries.

 

IdentityNow's data model is represented in JSON. All items in the JSON can be searched, and many of them are defined below. You can find samples of our JSON data models here.

 

Searching Identity Data

By looking at the JSON for IdentityNow's data, you can get an idea of how to search for each item. The way you search for data depends on where you find it within the JSON.

 

You can search first-level fields​ (also known as top-level fields) directly. To search second-level fields​ append them to a first-level field with a period. Use nested queries​ to search on other fields.

 

First-Level Fields for Identities

To search first-level fields, use the following format:

 

field:<search terms>

 

The following table contains a list of first-level fields in identities. Below the first-level fields, you can see second-level fields and nested-level fields, which are separated within the table and labeled. Second- and nested-level fields are described later in this document.

 

Field Type Description Example
name string The name or alias of the identity. name:john.smith
displayName string The identity's unique display name. This is the same as attributes.displayName. In some cases, this is also the same as the name. displayName:john.smith
id string The technical ID of the identity in IdentityNow. id:abc1
email string The identity's unique email address. email:steve@acme.com
created date The date that the first source account for this identity was aggregated into IdentityNow, even if that account didn't come from the authoritative source. This date requires any ISO format that uses YYYY-MM-DD. created:2017-09-25
modified date The date the identity was last modified in any ISO format that uses YYYY-MM-DD. modified:2018-03-30
phone string The identity's alternate phone number. phone:5558675309
status string The status of the identity. status:UNREGISTERED
synced date The date and time that this identity's information was last verified in any ISO format that uses YYYY-MM-DD. synced:2019-03-25
isManager bool A boolean describing whether the identity is listed as the manager of another employee. isManager:TRUE
employeeNumber string The identity's unique employee number. employeeNumber:123
processingState string This field is blank unless the identity experienced an error during aggregation, in which case this field will be ERROR. processingState:ERROR
appCount integer The number of apps the identity has access to. appCount:6
accountCount integer The number of sources the identity has an account on. accountCount:4
accessCount integer The number of access items the identity has. This includes entitlements, access profiles, and roles. accessCount:16
entitlementCount integer The number of entitlements the identity has. entitlementCount:10
roleCount integer The number of roles the identity has. roleCount:4
accessProfileCount integer The number of access profiles the identity has. accessProfileCount:7
Second- and Nested-Level Fields
Fields Description
manager Search for identities who have managers with certain characteristics. This object requires a second-level field. See below for details.
source Search for identities based on the information in their authoritative source. This object requires a second-level field. See below for details.
identity profile Search for identities who belong to a specific identity profile. This object requires a second-level field. See below for details.
owns Search for identities who own specific items in IdentityNow, such as access profiles, sources, or roles.
attributes Search for identities with specific identity attributes. This object requires a second-level field. See below for details.
apps Search for identities by which apps they have. This nested object requires a nested query. See below for details.
accounts Search for identities by which source accounts they have. This nested object requires a nested query. See below for details.
access Search for identities by what specific access they have. This nested object requires a nested query. See below for details.

 

NOTE: When you search on displayName, all identities with that displayName are returned, as well as all identities that have someone with that displayName listed as their manager.

 

Second-Level Fields for Identities

Second-level fields are a type of object. Each second-level field contains at least one first-level field. They can give you additional information about your identities and their data.

 

To search second-level fields, use the following format:

 

secondLevelField.firstLevelField:<search terms>

 

For example, attributes.firstname:John will return all identities with John in their firstname attribute in your org.

 

The following table contains all available second-level objects on identities, and the fields they contain.

 

Second-Level Field First-Level Field Type Description Example
manager name string The name of the identity's manager. This corresponds to the name field for the manager. manager.name:amanda.ross
displayName string The display name of the identity's manager. This corresponds with the displayName field for the manager. In some cases, this is the same as the name. manager.displayName:amanda.ross
id string The technical ID of the manager's identity. manager.id:abc1
source id string The technical ID of the identity's authoritative source. source.id:abc1
name string This represents the name of the identity's authoritative source. source.name:acme.source
identityProfile name string The name of the identity profile. identityProfile.name:Employees
id string The technical ID of the identity profile. identityProfile.id:abc1
owns sources.name string The display name of the source the identity owns. owns.sources.name:"Active Directory"
sources.id string The technical ID of the source the identity owns. owns.sources.id:abc1
accessProfiles.name string The display name of the access profile the identity owns. owns.accessProfiles.name:"Engineering Management Access Profile"
accessProfiles.id string The technical ID of the access profile the identity owns. owns.accessProfiles.id:abc1
roles.name string The display name of the role the identity owns. owns.roles.name:Engineers
roles.id string The technical ID of the role the identity owns. owns.roles.id:abc1
governanceGroups.name string The display name of the governance group the identity owns. owns.governanceGroups.name:"IT Team"
governanceGroups.id string The technical ID of the governance group the identity owns. owns.governanceGroups.id:abc1
applications.name string The display name of the application the identity owns. owns.applications.name:Acme
applications.id string The technical ID of the application the identity owns. owns.applications.id:abc1
attributes uid string The UID as it appears on the identity profile. This comes from the authoritative source. attributes.uid:abc1
firstname string The identity's first name. attributes.firstname:Rakesh
cloudAuthoritativeSource string The technical ID of the authoritative source of the identity profile. attributes.cloudAuthoritativeSource:abc1
cloudLifecycleState string The lifecycle state configured for the identity. attributes.cloudLifecycleState:Active
phone string The identity's alternate phone number. attributes.phone:5551235555
displayName string The identity's unique display name. This is the same as displayName. In some cases, this is also the same as the name. attributes.displayName:amanda.ross
identificationNumber string The identity's employee number as configured in the identity profile. attributes.identificationNumber:293409
workPhone string The identity's work phone number. attributes.workPhone:5551235555
email string The email address of the identity. attributes.email:o.price42@acme.com
lastname string The identity's last name. attributes.lastname:kim
startDate date The date the identity started at your company in ISO 8601 format. attributes.startDate:2016-04-25
endDate date The date the identity's employment at your company ended in ISO 8601 format. attributes.endDate:2019-01-25
personalEmail string The identity's alternate email address. attributes.personalEmail:samantha.dobbs@gmail.com

 

Note that if you add custom attributes to your identity profile, you can search on those as well using the technical name of the attribute. You can also configure your custom attributes to use the date type of value by adding the string dateType to the end of your attribute name.

 

Nested-Level Fields for Identities

If an identity is able to have more than one of a particular type of item, it must be searched with a nested query. Apps, accounts, and access are nested objects, and require nested queries.

 

To create a nested query, write your query in the format @nestedObject(secondLevelField.firstLevelField:query). See Using Nested Queries for details.

 

The following table contains a list of all nested objects on identities, their second-level fields, and the first-level fields they contain.

 

Nested Object
Second-Level Field First-Level Field Description Example
apps   id The technical ID of the app. @apps(id:386)
  name The display name of the app. @apps(name:Adobe)
source name The display name of the source that grants the app. @apps(source.name:acme_source)
id The technical ID of the source that grants the app. @apps(source.id:abc1)
account id The technical ID of the user's account on the source that grants the app. @apps(account.id:abc1)
accountId The user's display name for the account on the source that grants the app. @apps(account.accountId:"Amanda Ross")
accounts   id The ID of the account.

@accounts(id:abc1)

  name The display name of the account. @accounts(name:Amanda Ross)
  accountId If available, it's the aiqAccountName from the source. If not, it's the display name for the account.

@accounts(accountId:"cn=I17Manager1,dc=flatfile,dc=endtoend,dc=com")

  disabled A boolean based on whether identities have disabled accounts. Accounts can be disabled from the UI. This field is case sensitive. @accounts(disabled:TRUE)
  locked A boolean based on whether identities have locked accounts. This could be due to invalid login attempts. This field is case sensitive. @accounts(locked:FALSE)
  privileged A boolean  based on whether identities have accounts marked as privileged. This is determined on the source itself. @accounts(privileged:TRUE)
  manuallyCorrelated A boolean based on whether identities have accounts that were manually correlated. This field is case sensitive. @accounts(manuallyCorrelated:FALSE)
  passwordLastSet The date in ISO YYYY-MM-DD format that the password for the account was last changed. @accounts(passwordLastSet:2018-04-05)
  created The date in ISO YYYY-MM-DD that an identity's account on a source was first created. @accounts(created:2017-10-17)
entitlementAttributes memberOf The entitlement attributes and values associated with the account. @accounts(entitlementAttributes.memberOf:"manager entitlement")
source name The display name of the source the account is on. @accounts(source.name:"Acme Source")
id The technical ID of the source the account is on. @accounts(source.id:abc1)
type The type of source the account is on. @accounts(source.type:DelimitedFile)
access   id The technical ID of the access item. @access(id:abc1)
  type The type of access item. @access(type:ENTITLEMENT)
  displayName The display name of the access item, as configured in the UI. This is the same as access.name. @access(displayName:"Manager Entitlement")
  name The name of the access item, as configured in the UI. This is the same as access.displayName. @access(name:"Manager Entitlement")
  description The description of the access item, as entered in the UI. @access(description:"Entitlement given to managers in Engineering")
  privileged A boolean based on whether the access item is marked as privileged. For access items that are not entitlements, this boolean describes whether the access item contains an entitlement that is marked as privileged. @access(privileged:FALSE)
  attribute For entitlements, the attribute used by the source to define the type of entitlement. @access(attribute:memberOf)
  value For entitlements, the value used by the source for the entitlement. @access(value:"manager entitlement")
  disabled For roles, a boolean based on whether the role is enabled or disabled in the UI. This field is case sensitive. @access(disabled:FALSE)
source name The display name of the source the access comes from. @access(source.name:"Active Directory")
id The technical ID of the source the access comes from. @access(source.id:abc1)
owner id The technical ID of the access owner. @access(owner.id:abc1)
name The access owner's name as it appears in the identity list. @access(owner.name:amanda.ross)
displayName The access owner's display name as it appears in the identity list. @access(owner.displayName:"Amanda Ross")

 

Back to Top

 

Searching Entitlement Data

The entitlement data model describes the data found within an entitlement. Currently, all entitlements only contain first-level fields. All fields can be searched.

 

See the entitlement data model here.

 

Field Type Description Example
id string The technical ID of the entitlement. id:abc1
displayName string The display name of the entitlement, as seen in the UI. displayName:"Manager Entitlement"
name string The entitlement name. name:"manager entitlement"
description string The user-entered description of the entitlement. description:"The entitlement assigned to managers."
privileged bool A boolean describing whether or not the entitlement is marked as privileged. privileged:TRUE
attribute string The attribute used by the source to define the type of entitlement. attribute:memberOf
value string The value used by the source for this entitlement. value:"manager entitlement"

 

modified

date The date the entitlement was last modified, in ISO YYYY-MM-DD format. modified:2017-05-14
synced date The date and time that this entitlement's information was last verified in any ISO format that uses YYYY-MM-DD. synced:2019-03-21
source.name string The name of the source the entitlement comes from. source.name:"Acme Source"
source.id string The ID of the source the entitlement comes from. source.id:abc1

 

Back to Top

 

Searching Access Profile Data

The access profile data model describes the information you can find about access profiles in your IdentityNow implementation. You can see the data model for access profiles here.

 

First-Level Fields for Access Profiles

The following table contains a list of first-level fields in access profiles. First-level field searches use the following format:

 

field:<search terms>

 

Field Type Description Example
created date The date the access profile was created, in ISO YYYY-MM-DD format. created:2018-03-17
description string The user-entered description of the access profile. description:"Grants users access to Acme App."
entitlementCount integer The number of entitlements in the access profile. entitlementCount:3
id string The technical ID of the access profile. id:abc1
modified date The date the access profile was last modified, in ISO YYYY-MM-DD format. modified:2018-07-15
name string The name of the access profile. name:"Acme App Admin Access"
requestable bool A boolean describing whether or not this access profile is marked as requestable. This field is case sensitive. requestable:TRUE
synced date The date and time that this access profile's information was last verified in any ISO format that uses YYYY-MM-DD. synced:2019-03-23
owner.name string The name of the owner of the access profile. owner.name:"Kirsten Jones"
owner.id string The technical ID of the owner of the access profile. owner.id:abc1"
owner.type string The type of entity that owns this access profile. This is always an identity. owner.type:identity
owner.email string The work email address of the identity that owns the access profile. owner.email:"patricia.jones@acme.com"
source.name string The name of the source of the entitlements in the access profile. source.name:"Active Directory"
source.id string The technical ID of the source of the entitlements in the access profile. source.id:abc1

 

Nested-Level Fields for Access Profiles

If an access profile is able to have more than one of a particular type of item, it must be searched with a nested query. This means that entitlements within access profiles must be searched with a nested query.

 

To create a nested query, write your query in the format @nestedObject(firstLevelField:query). See Using Nested Queries for details.

 

Nested Object Field Type Description Example
entitlements attribute string The attribute used by the source to define the type of entitlement. @entitlements(attribute:memberOf)
description string The user-entered description of the entitlement. @entitlements(description:"The entitlement assigned to managers.")
id string The technical ID of the entitlement. @entitlements(id:abc1)
name string The entitlement name. @entitlements(name:"Manager Entitlement")
value string The value used by the source for this entitlement. @entitlements(value:managerEntitlement)

 

Back to Top

 

Searching Role Data

The role data model describes the data found in roles. Currently, roles contain first-level fields. All of these fields can be searched. You can see the data model for roles here.

 

Field Type Description Example
name string The user-entered name of the role. name:"Accounting Role"
id string The technical ID of the role. id:abc1
description string The user-entered description of the role. description:"This is a role for accountants."
created date The date the role was created, in ISO YYYY-MM-DD format. created:2017-11-18
modified date The date the role was last modified, in ISO YYYY-MM-DD format. modified:2018-08-25
enabled bool A boolean describing whether the role is enabled. This field is case sensitive. enabled:FALSE
requestable bool A boolean describing whether the role is requestable. This field is case sensitive. requestable:TRUE
synced date The date and time that this role's information was last verified in any ISO format that uses YYYY-MM-DD. synced:2019-03-20
accessProfileCount integer The number of access profiles granted by the role. accessProfileCount:3
accessProfiles.id array Any of the technical IDs of the access profiles granted by the role. accessProfiles.id:abc1
accessProfiles.name array Returns all roles that contain the access profile you search for. accessProfiles.name:"Access Profile 1"
owner.id string The technical ID of the owner of the role. owner.id:abc1
owner.name string The name of the owner of the role. owner.name:"Bill Snide"
owner.type string The type of entity that owns this role. This is always an identity. owner.type:identity
owner.email string The work email address of the identity that owns this role. owner.email:"jackie.smith@acme.com"

 

Back to Top

 

Searching Event Data

The data model for events describes how IdentityNow stores audit events. IdentityNow's audit events contain first-level fields and second-level fields.

 

Events are how IdentityNow tracks audit data. Using Search, you can create and download a custom audit report.

 

See the event data model here.

 

First-Level Fields for Events

In an event's first-level fields, you can find basic metadata about the event.

 

Learn more about searching on first-level fields.

 

Field Type Description Example
created date The date and time the event began, in ISO 8601 format. created:2019-01-25
name string A user-friendly translation of the technical name. name:"Create Source Passed"
operation string The action performed during the event. This is also captured in the technicalName. operation:CREATE
status string The result of the event. status:PASSED
technicalName string The normalized name of the event. This always follows the pattern objects_operation_status. technicalName:SOURCE_CREATE_PASSED
details string When available, a description of the event. details:"User approved access request for app."
type string The type, or classification, of the event. type:SOURCE_MANAGEMENT
id string The technical ID of the event. id:abc1
ipAddress string The IP address of the target system, such as the app a user is signing in to or the source that the user is changing the password for. ipAddress:207.123.123.150
objects string The object the event is happening to. In some cases, there is more than one domain object. objects:SOURCE
action string The name of the event as it appeared in legacy audit reports. action:CONNECTOR_CREATE
trackingNumber string The ID of the group of events. Sometimes, this ID will be the same for multiple related events. This tracking number might also match the tracking number for an account activity entry. trackingNumber:abc1

 

Second-Level Fields for Events

Second-level fields are a type of object. Each second-level field contains at least one first-level field.

 

To search second-level fields, use the following format:

 

secondLevelField.firstLevelField:<search terms>

 

Second-Level Field First-Level Field Type Description Example
actor name string The name of the identity, source, or system that generated this event. actor.name:"Andrew Beck"
target name string The name of the recipient of the event. This can be an identity, source, or system. target.name:"Active Directory"
attributes sourceName string The name of the source involved in the event. attributes.sourceName:"Active Directory"
accountName string For provisioning events such as attribute sync, this is the native identity on the source account being modified. attributes.accountName:"andrew-beck"
appId string For provisioning events such as attribute sync, this is the technical ID of the source being modified. attributes.appId:"abc1"
previousValue string For provisioning events, the previous value of the attribute on the source that was modified. attributes.previousValue:"555-555-1234"
attributeValue string For provisioning events, the new value of the modified attribute on the source. attributes.attributeValue:"555-555-9876"
provisioningResult string For provisioning events, the status of the completed provisioning action. This will always be either COMMITTED or FAILED. attributes.provisioningResult:COMMITTED
sourceId string In most cases, this is the technical ID of the source involved in the event. For provisioning events, this is the API ID of the source. attributes.sourceId:abc1
interface string The internal name of the IdentityNow process. This is only used for attribute sync events. The term should be, "Attribute Synchronization Refresh." attributes.interface:"Attribute Synchronization Refresh"
error string The error message returned when the event is an error. attributes.error:"Error log: Source not found."
Advanced users might want to search on other fields in the attributes field. Because each audit event has a different set of attributes, we do not document all fields associated with this object.

 

Back to Top

 

Searching Account Activity

The account activity data model covers most activity that IdentityNow completes on a source account. You'll see the following types of actions when you search for account activity:

 

  • Access Request - Search on access requests.

  • Account Attribute Update - Search for events that involved updating a single attribute on an account.

  • Account State Update - Search for events that involved locking or unlocking an account on a source.

  • Certification - Search for events involving removing an entitlement from a user as a result of the entitlement being revoked during a certification.

  • Cloud Automated <Lifecyclestate> - Search automated lifecycle state changes that resulted in an identity being assigned to a different lifecycle state. The <Lifecyclestate> variable will be replaced with the name of the lifecycle state that identities changed to.

  • Identity Attribute Update - Search on the times when an identity's attribute was updated within IdentityNow as the result of a provisioning action. When updating an identity attribute also updates an identity's lifecycle state, you'll also see the event Cloud Automated <Lifecyclestate>. Updates to identity attributes that occur as a result of an aggregation are not included in Account Activity. 

  • Identity Refresh - Search identity refreshes that happen whenever a user gets a new role, whenever an identity profile is updated, or whenever an app is assigned to users based on that app being assigned to All Users From Source or Specific Users From Source.

  • Lifecycle State Refresh - Search the actions that took place when a lifecycle state was changed. This event only occurs after Cloud Automated <Lifecyclestate> or Lifecycle State Change.

  • Lifecycle State Change - Search account activity that resulted in an identity being manually assigned to a null lifecycle state.

  • Password Change - Search password changes on sources.

 

When you search on account activity, you'll see only the set list of results described above. Each of those actions represents a specific event that occurred in your site.

 

You can search on attribute sync provisioning events in the Events tab.

 

To search for account activity, use the fields contained within the data model. Account activity contains first-level fields, second-level fields, and nested fields.

 

See the account activity data model here.

 

First-Level Fields for Account Activity

In an account action's first-level fields, you can find basic metadata about the request.

 

First-level field searches use the following format:

 

field:<search terms>

 

Field Type Description Example
action string The action performed. This will always match an action in the list above. action:"Password Change"
status string The overall status of the account activity. status:complete
id string The technical ID of the request. id:acb1
trackingNumber string The tracking number, which is sometimes used for auditing purposes. This tracking number might also match the tracking number for an event entry. trackingNumber:1234
created date The date the action was created in any ISO format that uses YYYY-MM-DD. created:2018-08-13
modified date The date of the last activity related to the action in any ISO format that uses YYYY-MM-DD. modified:2018-09-13
sources list The sources involved in the account activity. Searching on one source in this list will return all account activity that has that source within the sources list. This field is case sensitive. sources:"Active Directory"
stage string The progress of the action, provided by the source. stage:executing
errors list Any errors that the source provided while completing account actions. errors:"Unable to provision to this source."
warnings list Any warnings the source provided while completing account actions. warnings:"New value equal to old value."
Second- and Nested-Level Fields
Fields Description
requester

Search for account activity based on data about the system or person that first triggered the actions. This object requires a second-level field. See below for details.

recipient

Search for account activity based on data about the system or person being modified by the account actions. This object requires a second-level field. See below for details.

originalRequests

Search for account activity based on data about the original action that triggered all individual source actions related to this account action. For example, a lifecycle state change, a role change, a password update, etc. This object requires a nested query. See below for details.

accountRequests

Search for account activity based on data about each individual source action that was triggered by the original request. This might include an entitlement being granted, an attribute update, a single account being created, etc. This object requires a nested query. See below for details.

expansionItems

Search for account activity based on the controls that translated the attributeRequests into actual provisioning actions on a source. This object requires a nested query. See below for details.

approvals

Search for account activity based on data about the approvals or rejections performed on an item. This item only applies to access requests. This object requires a nested query. See below for details.

 

Second-Level Fields for Account Activity

Second-level fields are a type of object. Each second-level field contains at least one first-level field. They can give you additional information about your identities and their data.

 

To search second-level fields, use the following format:

 

secondLevelField.firstLevelField:<search terms>

 

For example, the search query requester.name:"john smith" will return all account activity that was initiated by John Smith.

 

Second-Level Field First-Level Field Type Description Example
requester id string The technical ID of the user or system that requested the action. requester.id:abc1
name string The display name of the user or system that requested the action. requester.name:bob.smith
recipient id string The technical ID of the user or system that the action is modifying. This is sometimes the same as the requester. target.id:abc1
name string The display name of the user or system that the action is modifying. This is sometimes the same as the requester. target.name:john.jones

 

Nested-Level Fields for Account Activity

If an account action is able to have more than one of a particular type of item, it must be searched with a nested query. Account activity also has originalRequests information, which uses a nested query even though an account action can only have one original request item. Account activity's nested objects are described below.

 

  • originalRequests - The original account action within IdentityNow that triggered all related source actions. For example, a role being granted is an original request.
  • accountRequests - Each account request is a description of the changes made to an individual source. You'll see the original request duplicated here.
    NOTE: Both originalRequests and accountRequests contain a field called attributeRequests. Each attribute request is a granular description of each individual attribute that must be modified on the source.
  • expansionItems - Each account action will have one expansion item for every attribute request. The expansionItems field is an internal logging mechanism to help SailPoint troubleshoot account activity, and includes details about why each attributeRequest was completed the way it was.
  • approvals - Approval items are present only for access request account actions. They include information about who the reviewers were and any comments they left.

 

To create a nested query, write your query in the format @nestedObject(secondLevelField.firstLevelField:query).

 

The following table contains a list of all nested objects and the fields they contain.

 

Nested Object Second-Level Field First-Level Field Type Description Example
originalRequests   accountId string The account ID of the user on the source that the request was made for. @originalRequests(accountId:sam.smith
  op string The requested operation. This can be create, modify, lock, unlock, enable, disable, or delete. @originalRequests(op:create)
source id string The technical ID of the source that the actions will happen on. @originalRequests(source.id:abc1)
name string The name of the source that the actions will happen on. @originalRequests(source.name:"Active Directory")
displayName string The display name of the source that the actions will happen on. @originalRequests(source.displayName:"Active Directory")
type string The type of source that's being modified as the result of these actions. @originalRequests(source.type:"Generic Flat File")
provisioningTarget id string The technical ID of the source that's fulfilling the request. @originalRequests(provisioningTarget.id:abc1)
name string The display name of the source that's fulfilling the request. @originalRequests(provisioningTarget.name:"Active Directory")
type string The type of source that's being modified as the result of these actions. @originalRequests(provisioningTarget.type:"Active Directory")
attributeRequests op string The operation for an individual attribute that must be edited. This might be add, set, or remove. @originalRequests(attributeRequests.op:add)
name string The name of the individual attribute that's being updated. @originalRequests(attributeRequests.name:displayName)
value string The new value of the attribute that's being updated. @originalRequests(attributeRequests.value:"Bob Dobbs")
accountRequests   accountId string The native identity that the request was made for. @accountRequests(accountId:"cn=I17Manager1,dc=flatfile,dc=endtoend,dc=com")
  op string The requested operation. This can be create, modify, lock, unlock, enable, disable, or delete. @accountRequests(op:enable)
source id string The technical ID of the source that the actions will happen on. @accountRequests(source.id:abc1)
name string The name of the source that the actions will happen on. @accountRequests(source.name:"Active Directory")
displayName string The display name of the source that the action will happen on. @accountRequests(source.displayName:"Active Directory")
type string The type of source that's being modified as the result of these actions. @accountRequests(source.type:"Generic Flat File")
provisioningTarget id string The technical ID of the source that's fulfilling the request. @accountRequests(provisioningTarget.id:abc1)
name string The display name of the source that's fulfilling the request. @accountRequests(provisioningTarget.name:"Active Directory")
type string The type of source that's being modified as the result of these actions. @accountRequests(provisioningTarget.name:"Generic Flat File")
result status string The status of the individual action on the specific source. @accountRequests(result.status:retry)
errors string Any errors that the source provided while completing account actions. @accountRequests(result.errors:"There was an error during provisioning.")
warnings string Any warnings that the source provided while completing account actions. @accountRequests(result.warnings:"Warning: Memory running low.")
ticketId string If a ticket has been created in an external system such as ServiceNow to track the provisioning for this request, this is the ticket ID that has been provided to IdentityNow. @accountRequests(result.ticketId:1234)
attributeRequests op string The operation for an individual attribute that must be edited. This might be add, set, or remove. @accountRequests(attributeRequests.op:set)
name string The name of the individual attribute that's being updated. @accountRequests(attributeRequests.name:lastName)
value string The new value of the attribute that's being updated. @accountRequests(attributeRequests.value:Jones)
expansionItems   accountId string The unique account identifier for the account being modified. @expansionItems(accountId:Andrew.Beck)
  cause string The internal reason why this attributeRequest is being performed. This can be Role, AttributeSync, AttributeAssignment, or ProvisioningPolicy. @expansionItems(cause:Role)
  name string Additional information about the reason this attributeRequest is being performed. @expansionItems(name:"Accounting Role")
source name string The name of the source that the account being modified is on. @expansionItems(source.name:AD)
id string The technical ID of the source the account being modified is on. @expansionItems(source.id:abc1)
type string The type of source that the account being modified is on. @expansionItems(source.type:"Active Directory")
attributeRequest op string The operation for an individual attribute that must be edited. This might be add, set, or remove. @expansionItems(attributeRequest.op:set)
name string The name of the individual attribute being updated on the source. @expansionItems(attributeRequest.name:roleAttribute)
value string The new value of the attribute being updated. @expansionItems(attributeRequest.value:"Accounting Manager")
approvals   workItemId string The technical ID of the approval item. @approvals(workItemId:abc1)
  created date The date that the approval item was created. @approvals(created:2018-08-13)
  modified date The date that the approval item was last modified in any ISO format that uses YYYY-MM-DD. @approvals(modified:2018-08-16)
  result string The status of the approval item. This can be Finished or Rejected. @approvals(result:finished)
comments commenter string The display name of the user who left the comment. @approvals(comments.commenter:bob.smith)
comment string The comment that was left on the approval item. @approvals(comments.comment:"This access is privileged and is not appropriate for this requester.")
date date The date that the comment was left in any ISO format that uses YYYY-MM-DD. @approvals(comments.date:2018-08-16)
owner name string The name of the reviewer of the access request. @approvals(owner.name:jane.smith)
id string The technical ID of the reviewer of the access request. @approvals(owner.id:abc1)

 

Back to Top

 

Structuring a Search

Once you're familiar with the fields that are available for you to search on, you can start constructing queries. You can use those fields and choose search terms to find important information about your identities.

 

In a search, a field is where you search, and a term is what you search for.

 

In most queries, your search will look like this:

 

field:term

 

Make sure not to put spaces in the field portion of your query, or after the colon following the field. If you have spaces in your term, put them in double quotes. All spaces that aren't in double quotes will be treated as an OR operator.

 

Search Terms

Terms are simply words you use in a query.

 

Some terms can be searched on with no other words in the query.

 

Single-word terms can be searched alone or with double quote marks surrounding them. If you search using quote marks, the search results will contain all words in your query.

 

Description of Results
Query
All identities with any attribute that contains the word london are returned. london
All identities with any attribute that contains the word sydney are returned. sydney
All identities with any attribute that contains the phrase sao paulo are returned. "sao paulo"

 

A query without a field, like the ones above, searches all identity data. For example, searching on "london" returns all identities in London - but also all identities who are named London, or who have any entitlements based in London.

 

If you want to specify which search categories to return, click the filter icon next to the Search bar. To specify which data about the search category to return, use fields.

 

Quotation Marks

You can use quote marks to help you make your query more specific.

 

Single-quotes are treated as an ordinary character. If there's more than one word in single quotes, our search engine treats the terms as if they have an OR operator between them.

 

Double quotes should be placed around words that must be searched exactly, or as a phrase.

 

Description of Results Query
All results that contain the words sao or paulo are returned. sao paulo
All results that contain the words sao or paulo are returned. 'sao paulo'
All results that contain the phrase sao paulo are returned. "sao paulo"
All identities that have the phrase sao paulo listed as their location are returned. attributes.location:"sao paulo"

 

First-Level Fields

First-level field searches are constructed using this format:

 

field:term

 

All fields are based on the IdentityNow data model. You can specify the field for anything you search for. In Elements of a Search, you can find the items that can be searched with first-level fields.

 

Description of Results Query
Returns identities with john.smith as their IdentityNow display names. displayName:john.smith
Returns all identities that were created on June 1, 2018. created:2018-06-01
Returns all identities that are listed as Active in the identity list. status:ACTIVE

 

Second-Level Fields

Second-level field searches from any search category are constructed using the following format:

 

secondLevelField.firstLevelField:term

 

All objects and fields are based on the IdentityNow data model. Second-level fields are present in identity data, event data, and account activity data.

 

Description of Results Query
Returns all identities that have the word london in the location attribute on their identity profile. attributes.location:london
Returns all identities that have Amanda Ross as their manager. manager.name:amanda.ross
Returns a list of identities that are in an identity profile called ID_Profile_1. identityProfile.name:ID_Profile_1
Returns a list of account activity that was initiated by the user bob.dobbs. requester.name:bob.dobbs

 

Combining Multiple Search Criteria

You can include more than one criteria in your query to narrow down results.

 

When you're combining multiple search criteria, make sure you're using fields from the same search category. For example, searching for a field from identity data and a field from account activity data in the same query won't return any results.

 

Using Operators

Combine queries using operators. All operators must always be in all capital letters. If you don't specify an operator between two queries, the OR operator will be used.

 

OR

 

The OR operator, which can be symbolized by ||, links two terms, and finds a matching identity if either term exists anywhere in the item.

 

Description of Query Query
Search for identities that have the text sao paulo or london anywhere in their identity data "sao paulo" OR london
Using fields, search for identities that list Sao Paulo or London as their location. attributes.location:"sao paulo" OR attributes.location:london
Search for identities in Sao Paulo or London using the symbols for the OR operator. attributes.location:"sao paulo" || attributes.location:london

 

AND

 

The AND operator, which can be symbolized by &&, returns items which have both of your search terms in the identity data.

 

Description of Query Query
Search for identities that have the text london and amanda.ross anywhere in their identity data. london AND amanda.ross
Search for identities that have their location listed as London, whose manager is Amanda Ross. attributes.location:london AND manager.name:amanda.ross
Using symbols in place of the AND operator, search for identities in London whose manager is Amanda Ross.

attributes.location:london && manager.name:amanda.ross

 

NOT

 

The NOT operator, which can be symbolized with !, excludes search items that contain the term you enter after NOT.

 

Description of Query Query
Search for identities that contain the text amanda.ross that don't contain the text london. amanda.ross NOT london
Specify fields to search for identities whose manager is amanda.ross who aren't located in London. manager.name:amanda.ross NOT attributes.location:london
Use symbols in place of the NOT operator to find identities with amanda.ross as their manager, who aren't located in London. manager.name:amanda.ross ! attributes.location:london
Search for identities who don't have amanda.ross listed as their manager. Note that because the ! operator is at the beginning of the query string, it must always be followed immediately by the query, with no space. !manager.name:amanda.ross

 

Range operators > and <

 

The greater than and less than operators (> and <) can be used to search for dates and numbers that are greater or less than the value you state. You can also use these operators with an equal sign (=> and <=) to symbolize greater than or equal to, or less than or equal to. Be sure not to add a space between the colon and your range operator.

 

Description of Query Query
All identities that have more than 12 apps appCount:>12
All identities created on or before February 4, 2015 created:<=2015-02-04

 

Combining Multiple Operators

 

You can determine how your query is evaluated using parentheses. Anything in parentheses will be evaluated as a single query within your original query.

 

Description of Query Query
Search for identities that have amanda.ross listed as their manager, are in London, and have the last name of either Trent or Primrose. attributes.location:london AND manager.name:amanda.ross AND (lastName:trent OR lastName:primrose)
This query returns the same results as the one above. The parentheses are slightly different. attributes.location:london AND manager.name:amanda.ross AND lastName:(trent OR primrose)

 

Wildcards

 

You can also include wildcards in any search you make. The * wildcard represents any number of characters, while the ? wildcard always represents only a single character.

 

Description of Query Query
Returns all search data in your site. *
Return all identities named Jon, John, Johnson, and Jan. j*n
Return identities named Jon and Jan only. j?n

 

Using the .exact Keyword

You can add .exact to your first- and second-level field searches for results that match the exact string including case sensitivity. You can also use the wildcards * and ?.  Adding .exact is not required to search on an email.

 

Use the .exact keyword to search on data that includes any characters that aren’t letters or numbers.

 

On identities, the .exact keyword is available for use with the following fields and field types :

  • name
  • displayName
  • lastName
  • firstName
  • description
  • All identity extended attributes
  • Other free text fields

 

See below for some examples of queries that use .exact and results.

 

Description of Results
Query
Returns only identities who have a manager named "amanda ross" in lowercase. manager.name.exact:"amanda ross"
Returns only identities who have the last name "Ross" with a capital R. lastName.exact:Ross
Returns only identities whose locations start with "Aus", such as Austin or Australia. attributes.location.exact:Aus*
Returns only identities that have an account source called "ad", not Azure AD or Active Directory. @accounts(source.name.exact:"ad")
Return identities with the name jon-smith. name.exact:"jon-smith"
Search for roles with the name TaxProject#2019. name.exact:"TaxProject#2019"

 

Using Range Queries

You can search for a range of numerical values in IdentityNow by using brackets.

 

Searching Between Inclusive Values: [ TO ]

If you'd like to search between two values and include those values in your results, use square brackets.

 

For example, the following query will return all identities who have accounts created during March of 2018.

 

@accounts(created:[2018-03-01 TO 2018-03-31])

 

Searching Between Exclusive Values: { TO }

If you'd like to search between two values but exclude those values from your results, use curly brackets.

 

For example, the following query will return only identities that have 2 or 3 accounts.

 

accountCount:{1 TO 4}

 

Using Nested Queries

You'll need to use a nested query to search for data when it's possible for a searchable category to have more than one of the item. Nested queries give IdentityNow more information so that it can search those fields correctly.

 

Nested queries follow a distinct format:

 

@<nestedObject>(<object.field:term>)

 

<nestedObject> is where you specify the type of data you're searching for.

 

<object.field:term> is where you'll enter the rest of your query.

 

Nested-level fields are present in identity data, access profile data, and account activity data.

 

If your search term is multiple words in a nested query, you should surround it with double quote marks. Results will exactly match the text in your query.

 

See below for some examples of complete nested queries that search for only one term.  Everything not in bold is the same between all queries.

 

Description Query
Searches within each identity's accounts for the source name, Acme.

@accounts(source.name:Acme)

Searches within each identity's access for items marked as privileged.

@access(privileged:TRUE)

Searches within each identity's apps for apps that have an account source identical to Azure AD.

@apps(source.name:"Azure AD")

Returns all account activity with one or more create action performed on a source. @accountRequests(op:create)
Returns all account activity that contained one or more actions that failed to complete successfully. @accountRequests(result.status:failed)

 

You can also combine nested queries with other queries.

 

Combine Two Nested Queries

@<nestedObject>(<object.field:term>) <operator> @<nestedObject>(<object.field:term>)

 

The <nestedObject> is the nested object in each nested query.

 

The <object.field:term> is the rest of your query. This is based on the format for nested queries.

 

The <operator> is AND, OR, or NOT, or their symbols.

 

See below for some examples of two or more nested queries combined.

 

Description Query
This query returns all identities who have an account on the Acme source, but don't have the Adobe app. @accounts(source.name:Acme) AND NOT @apps(name:Adobe)
This query returns all identities with disabled accounts who have an entitlement with the title Building_Access. @accounts(disabled:TRUE) && @access(name:Building_Access)
This query returns a list of all identities that have the access profiles Acme Accounts Payable and Acme Accounts Receivable. @access(name:"Acme Accounts Payable") AND @access(name:"Acme Accounts Receivable")

 

Combine a Nested Query and a Simple Query

@<nestedObject>(<object.field:term>) <operator> <simple_query>

 

The <nestedObject> is the nested object in your nested query.

 

The <object.field:term> is the rest of your nested query.

 

The <operator> is AND, OR, or NOT.

 

The <simple_query> is any complete simple query, such as those described in search terms, first-level fields, and second-level fields.

 

See below for some examples of nested queries combined with simple queries. Everything not in bold is the same between all queries of this type.

 

Description Query

This query returns a list of all identities that have amanda.ross listed as their manager and who have the access item that has the display name Engineering_Access.

@access(displayName:"Engineering_Access") AND manager.name:"amanda.ross"

This query returns a list of all identities in Chicago that have an access item exactly called Admin_Access.

@access(name:"Admin_Access") AND attributes.location:Chicago

This query returns a list of all identities who are listed as Not Invited in the identity list, who have an access item called Base Access.

status:"UNREGISTERED" AND @access(displayName:"Base Access")

 

You've finished the second document in our four-part series on how to use IdentityNow's Search feature. Take a look at the map below to decide how to proceed.

 

Learn the Basics Build a Search Query More Information Downloading Reports

Overview of Search

In this document, you can:

  • Take a tour of the main Search page
  • Learn Search terminology
  • Find examples of searches
  • Explore more Search pages

Take me to the top of this document. 

In this document, you can:

  • Learn about the fields you can search on
  • See how to put them together into a query

Learning More About Search

In this document, you can:

  • See frequently asked questions
  • Learn about IdentityNow's data model
  • Find additional Search information

Downloading Reports from the Search Interface

In this document, you can:

  • Learn about downloading default and custom reports from Search
  • Find out how to interpret those reports

 

Tags (1)
Version history
Revision #:
39 of 39
Last update:
‎Nov 17, 2020 01:10 PM
Updated by: