Step 4: Example Use Cases

Below are some use case examples so you can get a sense of how these features would be implemented in real-world scenarios.

Example 1:

Food Company X wants to create a search experience that is only available to their employees. They want Yext to build and host the whole website but want basic password protection on the site.

• To implement something like this, the customer would use Yext Pages and add a Password Authentication policy to the website so that only those with the global password would have access.

Example 2:

A healthcare company wants to use Search for a database of internal assets. Each of these assets has permissions at the user level that they want to extend into the search experience. Depending on who is running the search, the search results will change. They want this to work with their existing SSO.

There are 2 ways to implement this use case.

1. If the customer does not want to host their website with Yext (using Pages), they can configure Okta to pass external identities to Search when a user logs in to only display the relevant assets.
2. If the customer does want to integrate with Pages, configuring a SAML integration between the existing SSO and Yext would allow the customer to use their existing SSO to log users in, but then easily set up Yext Auth to integrate with authorized search. The customer can use External Authorization AND/OR Yext Auth (depending how the permissions are stored on entities) to configure which assets are returned in Search.

Example 3:

A finance company wants to use Search for sharepoint documents. Each sharepoint document has a user group ID associated with it and wants to permission search results with this user groups.

External Authorization is key for this situation. There are 2 options to choose from.

1. The customer can host their website outside of Yext, and grab users’ identities however they choose. These external identities are then passed to Search to use for External Authorization.
2. The customer can integrate with Yext Pages and manage their users with Yext Auth. Identity will be passed with user log-in and by associating external identities on Yext users, Search can respect External Authorization.

Example 4:

A software company wants to implement visitor tracking. They already generate a unique user ID for each visitor and want to be able to track every search and conversion at the visitor level.

• This customer can use visitor level analytics with Search. The user ID can be passed to Analytics, and Report Builder can dimension and filter by user ID.

Example 5:

The same software company wants to create an internal application for employee resources where users can run searches and view pages, but also log in to Yext Content to make changes only to the entities relevant to their team.

• This customer will have to manage their users in Yext using Yext Auth (or using a SAML integration with Yext Auth and their existing SSO). The application site they build will be protected by Yext Auth so only employees can access it. Each Yext user will have permissions in the platform to view and update only the specific entities and fields they are allowed to update.

Example 6:

The same company wants to create a help website where some information is fully public, some is only available to employees, and some is only available to actual customers.

• The customer would create a public website (outside of Yext), with the option of logging in if you are an employee or customer. Attached to each searcher is an identity that signifies if they are a public user (not logged in) or identity if the user is logged in to signify if they are an employee or customer. To implement, Yext will use External Identities and External Authorization.