TABLE OF CONTENTS

• Supported plans and account modes
• Overview
• 1. URL resolution logic for email notifications
  • Requester notifications
  • Agent, agent group, and journey request owner notifications
  • CC, watcher, and shared ticket notifications
  • Other areas that use portal URL resolution
• 2. Portal routing for approvals and journey tasks
• 3. Solution, purchase order, and contract approvals
• 4. System notifications 
• 5. User activation emails
• 6. Other modules and channels

Supported plans and account modes

Plans

• Freshservice Pro and Enterprise

• Freshservice for Business Teams Pro

Note: If you downgrade to a plan that does not support multiple portals, all secondary portals are deleted, leaving only the default portal. Review your portal setup before you change plans.

Account modes

The details regarding multiple requester portals in this article apply exclusively to accounts in 'Employee Support (ESM)' mode (that is, accounts with workspaces enabled). While accounts in 'Managed Services (MSP)' mode also have access to multiple portals, their rules and behavior may differ, and users must switch their account mode to Employee Support to utilize the specific capabilities described here.

Overview

When running multiple support portals, one aspect becomes more nuanced compared to a single-portal setup: the portal URL that appears in email notifications.

If you are new to multiple support portals, read Get started with multiple requester portals first to understand how portals, workspaces, and users are connected.

Every work-related email notification typically includes a link to the relevant work item, such as a ticket, approval, announcement, or the account itself. When there are multiple portals in the account, Freshservice has to decide which portal’s URL to use for each link. The choice depends on three things:

• Who is receiving the email: a requester, an agent, an approver, a watcher, and so on.

• The record involved (a ticket, change, journey request, and so on) and the workspace it belongs to.

• Which portals is the recipient allowed to sign in to.

This article walks through how that choice is made for each recipient and scenario.

Note: This logic applies only to accounts in ‘Employee Support’ mode with two or more portals. Single-portal accounts always use the one portal that exists.

1. URL resolution logic for email notifications

Requester notifications

A requester here is the user named in the Requester/Initiator fields of a record. If a user (irrespective of whether they are agents or requesters) is named in one of these fields, they are treated like a requester for URL selection.

To pick a portal URL for an email to the requester, Freshservice goes through three steps:

1. Build a list of portals the requester can use: Every portal that is both mapped to the record’s workspace and accessible to the requester is added to this list. For records that don’t belong to any workspace, such as user notifications and account-level notifications like plans and billing, every portal in the account that the requester can access is added instead.

2. For tickets, check the originating portal: If the user originally submitted the ticket through a portal, and the ticket is still in a workspace mapped to that portal, Freshservice uses the originating portal’s URL in the email as long as the requester continues to have access to it.

   Currently, this behavior is supported only for tickets. It does not apply to changes or journeys submitted through a portal. Also, when agents create incidents or issues from the agent portal, the source is often auto-populated as Phone. If the source is not captured as Portal before ticket creation, Freshservice will skip this step.

3. Pick from the list: 

• If exactly one portal is on the list, Freshservice uses its URL. 

• If there are multiple portals on the list, and for tickets, none of them is the originating portal, Freshservice picks the portal that was created earliest. For example, if the account’s default portal is mapped, it will be picked as it's the oldest portal in the account.

• If the user does not have access to any of the portals mapped to the workspace, Freshservice falls back to the oldest portal mapped to that workspace. The portal link is still included in the notification, although the user may not be able to sign in to that portal.

• If only one portal is mapped to the workspace, its link is always included in the notification, regardless of whether the user has access to the portal.

The stated logic applies to both private and public URLs.

Note: When a user receives a notification related to the same record but isn’t the requester of the underlying record, the logic differs. See the sections below for those cases.

Agent, agent group, and journey request owner notifications

An agent is the user assigned to resolve the record. Agents are assumed to have access to all portals in the account, as they are automatically mapped to them. As a result, portal selection for agent notifications is straightforward:

• For a record inside a workspace, Freshservice uses the URL of the earliest portal mapped to that workspace. 

• For a global record (example, user notifications), Freshservice uses the account’s default portal URL.

The stated logic applies to both private and public URLs. As of today, agent notifications always default to the oldest portal mapped to the record’s workspace, and this behavior cannot be customized. Please ensure that all agents who work in the mapped workspaces have access to that portal.

CC, watcher, and shared ticket notifications

• CC and Share notifications: These typically include multiple recipients in a single email. Instead of splitting the notification based on each recipient's portal access, Freshservice selects a single portal for the entire email.

To determine the portal, Freshservice first checks whether the requester originally submitted the ticket through a portal. If so, and the ticket still belongs to a workspace mapped to that portal, the originating portal is used. Otherwise, Freshservice selects a portal that is mapped to the ticket's workspace and is accessible to the requester. If the requester is no longer active, Freshservice picks the earliest-created mapped portal.

This behavior assumes that users who are CC'd on, or have access to, a shared ticket belong to the same organization as the requester and therefore have access to the same portal. As a result, the notification is not split into separate emails based on each recipient's portal access.

• Watcher notifications: Watcher notifications are always sent as individual emails. Since watchers are always agents, Freshservice applies the standard agent portal-selection logic for these notifications.

Other areas that use portal URL resolution

In addition to the notifications configured under Email Notifications, the requester and agent portal-selection logic is also used in the following areas:

• Ticket Reply Templates and Canned Responses: When an agent replies to a ticket (template found in email notification settings) or inserts a canned response, any portal URL included in the template is generated using the requester portal-selection logic. The user taken into consideration for resolving the URL is the ticket’s requester. If the requester is no longer active, Freshservice picks the mapped portal that was created earliest.

• Sharing Public Ticket Links
  When a user shares a public ticket link from the UI, the generated link points to the portal the user is currently signed into. If authentication is not required for the account, anyone with the link can access it.

2. Portal routing for approvals and journey tasks

Approvers and stakeholders aren’t the record requester, nor are they the assigned agent. To ensure the link in the email is contextual and it opens the correct portal, for example, Company A approval surfaces on the Company A portal. Freshservice tries to find a portal that both the requester (or journey initiator) and the approver/journey task owner can access.

This logic applies to:

• Approval actions triggered from the ticket or change UI.

• Journey tasks assigned to stakeholders

Here’s how Freshservice picks the URL:

1. It builds a list of portals the requester (or journey initiator) can access, counting only portals mapped to the record’s workspace.

2. It builds the same kind of list for the recipient.

3. In simpler setups where a workspace is mapped to a single portal, links point to that portal. If a workspace is mapped to multiple portals, the system identifies the portals that are common to both:

4. The portals mapped to the workspace.

5. The portals the user has access to.

If multiple matching portals are found, the system uses the first-created portal.

Example:
A workspace is mapped to Portal A and Portal B. The requester has access to Portal B, but the Approver has access to both Portals A and B. Since Portal B is the only portal common to both lists, links will point to Portal B. This is done only to provide a more contextual approval and journey task assignment experience.

4. If no portal appears in both lists, or if the requester isn’t valid, Freshservice picks the oldest created portal the recipient can access in that workspace. If the recipient can’t access any workspace-mapped portal, Freshservice falls back to the oldest portal mapped to the workspace.

Note:

• Email approval replies are never blocked. A recipient can grant approval by replying to the email, even if the link in the email doesn’t open a portal they can sign in to.

• The approval and journey task notifications are an exception to the general portal-linking logic used for agents and requesters.

• Guest users in Journeys don’t need to sign in to complete their tasks. Freshservice picks a portal only to generate a contextual URL for their email. If the journey request later moves to a different workspace, guest users can still open older links and complete their tasks, because journey task pages are public.

• This logic also applies to approvals triggered via workflow automation.

3. Solution, purchase order, and contract approvals

These approvals don’t have a requester, and the approvers are always agents, so the “common portal” step doesn’t apply. Freshservice picks the URL using the agent logic. Note that solution folder portal visibility doesn’t affect this; agents can open solutions from the agent interface regardless of which portal they signed in through.

4. System notifications 

Most system notifications are intended for agents and administrators and will include links that direct users to the account's default portal.

5. User activation emails

The portal link included in a user activation email depends on how the user account is created.

• Portal sign-up: If a user signs up through a portal and meets the email domain restriction as well as the portal's access criteria, the activation email includes a link to the same portal. If the user does not satisfy the access conditions, the user profile is not created and no activation email is sent.

• Manual user creation or app-driven provisioning: When a user is added manually or provisioned through an external application, Freshservice identifies all portals the user can access, sorts them by creation date, and includes the oldest accessible portal in the activation email.
  

Note: For manually created users, preference is given to the portal from which the admin/agent is currently logged in, provided the new user also has access to that portal.

• User creation through email: When a user is created as a result of sending an email to a support address, the user profile is always created because it is required for ticket creation. However, an activation email is sent only if the user has access to at least one portal mapped to the workspace that received the email. Otherwise, no activation email is sent.

• Portal URLs in Ticket Notifications: For users created through email, portal URL placeholders in ticket-related email notifications continue to resolve to portal links even if an activation email was not sent. In such cases, the placeholder resolves to the oldest created portal mapped to the workspace.

However, users will be able to sign in only if they satisfy the access criteria for that portal.

6. Other modules and channels

Unless explicitly mentioned in the sections above, all other modules and channels continue to use the default portal URL. Multi-portal awareness for these areas will be introduced in a future release.

The following currently use the default portal URL:

• Project notifications

• On-call and Status page email notifications

• Device42 (D42) related notifications

• Freddy solution suggestions and Email bot

• Scenario automations that use the Send email action

• Workflow emails:

  • Document generation emails 

  • Generic emails sent to agents, requesters, or users that contain a portal URL placeholder

Recommendation: If you need to direct users to a secondary portal, we recommend hardcoding the appropriate portal URL using placeholders until multi-portal support is available for generic emails.

'Service Desk name' placeholder resolution

The {{servicedesk name}} placeholder currently resolves to the account's default portal name, which is treated as the service desk name.
If you need to display a specific portal name in an email notification, we recommend hardcoding it for now. In a future update, the placeholder will be enhanced to resolve dynamically based on the portal URL included in the notification.