Designing an effective query for the Outlook Integration

The Outlook Integration can use an IQA query to search for and match contacts when saving emails.

Using a query provides flexibility to do the following:

  • Control which contacts are searchable
  • Define how results are displayed
  • Limit results based on business rules (for example, active members only)

However, poorly designed queries can negatively impact performance and usability. Following best practices ensures accurate results and a responsive user experience.

Required query structure

At a minimum, the query should return:

  • ID – Unique identifier for the contact (required)
  • Full Name – Used for display and recognition
  • Email – Used for matching email addresses. The query must return a column with a display name containing the word Email in order for it to work with iMIS Outlook Integration. If there are no checkboxes on a result, it means that record does not have an email address associated with it, or a column containing the word Email does not exist in the IQA query.
📘

Note

There is no limit to the number of filters for an IQA query used in iMIS Outlook Integration.

🚧

Warning

Once a recipient or recipients have been found, the top-level filter can be used to place the recipients under To, Cc, or Bcc.

Recommended best practices

Follow these design guidelines when creating your query:

  • Relate sources using ID or key fields, not names
  • Start with a single source, then add more only if needed
  • Limit the number of sources (ideally fewer than four)
  • Use optimized business objects such as NetContactData
  • Avoid unnecessary calculated fields or SQL expressions

These practices help ensure accurate results and reduce query complexity.

Performance considerations for large queries

Because the Outlook Integration executes the query in real time, large or complex queries can slow down search results. Review the following recommended limits:

  • Avoid returning more than 500 rows.
  • Limit displayed columns to only what is required, for example add filters such as active members only and contacts with an email address.
  • Avoid large text fields or attachments in results.
  • Avoid using the Contains filter unless necessary.
  • Test the query incrementally as you build it.

Poorly designed queries can impact not only the user experience but also overall system performance.

Examples

The following examples demonstrate common use cases for Outlook Integration searches.

Committee members

Returns contacts who belong to a specific committee.

Example structure:

  • Source: Committee + NetContactData
  • Filters: Committee name or committee ID
  • Display:
    • ID
    • Full Name
    • Email
  • Use case: Quickly associate emails with committee members when managing communications.

Event attendees

Returns contacts registered for a specific event.

Example structure:

  • Source: Event registration objects
  • Filters: Event Code
  • Display:
    • ID
    • Full Name
    • Email
    • Event Name
  • Use case: Save event-related emails to the correct attendee records.

Members with expired dues

Returns members whose membership has lapsed.

Example structure:

  • Source: Membership or billing objects
  • Filters: Expiration date < Today
  • Display:
    • ID
    • Full Name
    • Email
    • Membership status
  • Use case: Track and associate renewal-related communications.