criteria-based data exposure

criteria-based data exposure

Dear Customers,

We hope you're well!

Portals is a self-service avenue through which your clients can access and manage their direct and related data in Zoho CRM. This empowers them to be more independent and enables them to experience a sense of transparency with your business.
Here, the key term to notice is direct and related data. The current portal setup serves clients only with their own primary and related data via a lookup field. Here's a pictorial representation of the current setup:

While having access only to their records gives customers authority over their information, it presents some notable challenges.

Challenge #1: Lack of control
A record undergoes two types of processes: customer-driven processes like conversion, negotiation, winning a deal, and more, and internal processes like approvals, discussions, and rejections. While the former keeps customers informed about the progress of their deals, the latter reveals the business' internal decision-making process. Administrative information isn't necessarily meant to be seen, but the current portal setup exposes each stage a record goes through, unconditionally. This poses a problem: The business lacks control over the kind of information that's shared.

Imagine this scenario: Patricia is your customer. She has access to her profile, deals, and quotes. She can manage data all by herself and track records as they progress. While having access to her own records empower her with independence, witnessing all the process changes—including approvals and rejections of discounts that aren't yet final—might cause her some anxiety. It also violates the business's privacy policies.

Challenge #2: Lack of flexibility
The portals you have now only enable you to share clients' personal and transactional records. Clients can only see their own data. But what if they want to access information other than their own? Or what if they want to view records with a particular trait?
Say, for example, your business sells multiple products across Canada, and you want your portal users to see only the products available in their regions. This is a specific request that's based on the location of the customer. The current setup limits this requirement and fails to preserve context for the customer.

Thus, to give the admins control over any exposed information and simultaneously provide portal users with both flexibility and independence, we've developed an exciting addition to portals' data-sharing functionality: criteria-based data exposure.

Introducing criteria-based data exposure
Criteria-based data exposure is the ability to expose modules and data based on conditions that you use to control what data should be exposed and when, or to render contextual results for portal users.
Technically speaking, in addition to linking a primary module and a related module using lookup fields, admins can now define two types of criteria to expose other records with a particular trait in the module: match with fields and match with values.

Match with value: This criterion should be familiar to you as a seasoned Zoho CRM user. You can determine record eligibility by defining a field, operator, and qualifying value.

Example: Deal type is new business. All those deals that are new businesses will be displayed to the portal user.

Match with field: Here, the relationship between the related module and the primary module is established by mapping their fields. That is, the relationships between records in primary and related modules are established by fields with the same values.

Example: Implementation agent servicing area is the client's billing city.

Let's understand these criteria by addressing our initial challenges:

Solution for challenge #1 (lack of control)
By matching with value, we can allow Patricia to view her quote only after it reaches the approved stage. This way, your business's internal correspondence stays internal, and Patricia can track her quotes without any impact on her experience.

Below is how you can configure this feature. Again, let's suppose Patricia is your customer and that you want her to have access to her transactional data:
  1. Create a mutual lookup field called "Contact name" between the Contacts and Quotes modules.
  2. To control who can access this information, use the match by value criterion and add two conditions:
    1. Quote stage is approved
    2. Quote stage is not negotiating
      This way, Patricia's quote is visible only when it reaches the approved stage.
Solution for challenge #2 (lack of flexibility)
With the match with field criterion, your portal user can view all products that are available in Canada.

Let's look at how you can configure this functionality.
The Products module is a public module, accessible to all portal users, irrespective of their relationship to that module. To bring context to this setup, add a condition using the match by field criterion:
  • Available area is mailing country
Note:
In addition to configuring criteria, you can also use an "and/or" conditional to follow these criteria. That is, you can use both criteria and lookup, or either of the three (criteria, or match with values, or match with fields), or one of the criteria and lookup.

For example, let's say your Implementation Specialist module has an exhaustive list of agents that implement servers in different areas, with varying levels and types of expertise. To display the agents the user hired as well as other agents for reference, we can configure conditions, as shown below:
  • The primary module and the related module can be linked using the native lookup field to bring up agent records that users have hired directly.
  • To display other agents in the location, let's use conditions:
    • If the record matches with values, the customer can see all agents who belong to Michigan, Ohio, Chicago, Washington, and Indianapolis will be displayed.
    • If the record matches with fields, the customer can see all agents whose service region matches the contact's mailing state. 
This way, both the agents directly hired by the contact and those agents that are from a desired location are displayed for portal users' reference.

Thanks to these new criteria, we've updated the UI of the configuration page as well. What used to be called Filter by column (where the lookup value is selected) has been renamed to Linked as and conditions.
To understand the scope and impact of this enhancement, let's look at a couple more examples.

Example 1: Match with value
Let's say you sell electronics and accessories in bulk for large enterprise organizations. You've extended the following modules in portals for enterprise customers:
  • Primary module: Contacts
  • Related modules: Products, Invoices, Cases, Appointments
  • Public module: Channel partners
 
So that customers can look at all the products applicable for enterprise customers, you've formulated some criteria: Lookup and Match by value. Customer type is Enterprise.

Now clients can see their contact records, their products (thanks to the lookup connection), and products for enterprise customers (thanks to the match by value criterion), as well as invoices, cases, and appointments related to them, and, finally, all channel partners.

Example 2: Match by field
Saint Laurent Hospital is a multi-specialty hospital in Iowa. They let their patients manage their profiles, view their prescriptions, order medicines from the pharmacy, view lab results, and book appointments with doctors using a dedicated portal.

This is their setup:
  • Primary module: Patient's profile
  • Related modules: The Prescriptions module, Lab Results module, and Appointments module are related with the primary module via lookup fields, and the Doctors module via the Match by field criterion.
  • Public modules: Medicines 
As you can see, records with personal data (prescriptions, lab results, appointments) are directly linked to the patient's profile using lookup fields, and to map the doctors to the patients' ailments, the complaint field from the patient's profile is linked to doctors whose specialization is also the same as the ailment. This means that the patient can see all the doctors whose specialization matches their complaint.
(i.e.) Specialization contains Complaint. IBS specialist contains IBS

That's all for this enhancement to the Portals configuration.

We hope these criteria will enhance your clients' experiences with your business. If you have any questions or concerns, please drop a comment. Let's connect!

Release plan: This enhancement is available for users in all DCs.
Resources: Portals in Zoho CRM

Thanks and kind regards, 
Saranya Balasubramanian