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. Workflows and Scenario Automation
• 7. 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 a user assigned to resolve a record. Portal selection for agent notifications follows a straightforward rule:

• Workspace records: Freshservice uses the URL of the preferred portal configured for the workspace. By default, this is the oldest created portal mapped to the workspace. Admins can change the preferred portal from Workspace Settings > Edit Workspace.

• Global records: For records that are not associated with a workspace (for example, user notifications), Freshservice uses the account’s default portal URL.

This logic applies to both public and private portal URLs. Since Freshservice does not evaluate individual agent portal access when resolving these URLs (like how it does for requesters), ensure that all agents working in the workspace have access to the selected preferred portal.

How does preferred portal selection work?

The Preferred Portal setting is available only in accounts with multiple portals. It is not shown in accounts with a single support portal.

Admins with permission to edit workspace settings can select a preferred portal for each workspace. The selected portal determines the URL used in email notifications sent to agents, agent groups, and journey request owners when the email contains:

• A link to a record that directs the recipient back to the service desk.

• The {{servicedesk name}} placeholder.

Currently, this logic applies to all modules except those listed in Point 6.

The portal dropdown includes:

• Mapped portals: All portals mapped to the workspace, listed alphabetically.

• Default portal: The account’s default portal.

Key points:

• The default portal is listed even if it is not mapped to the workspace. This is because all portals provide access to the same underlying account. For example, if the same team of agents works across multiple workspaces, each with a different portal, but you want agents to always be directed to the account through the default portal, you can select the default portal as the preferred portal for those workspaces.

• For new workspaces, the account’s default portal is mapped to the workspace and set as the preferred portal by default. The preferred portal remains unchanged until an admin manually updates it.

• Portal–workspace mapping changes: If a portal is removed from a workspace and it was the workspace’s preferred portal, admins will be notified of the impact. The oldest portal mapped to that workspace will then automatically become the new preferred 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.

• Delegates receive the same approval link as the delegator, even if the delegate does not have access to the portal.

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 include links that direct users to the account’s default portal. For key workspace-related system notifications (e.g., workspace creation or restriction), links will instead direct agents to the accessible portal mapped to that workspace.

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. Workflows and Scenario Automation

Emails triggered through workflows and scenario automations follow the existing recipient-resolution logic:

• Send email to agent: Uses the current agent logic.

• Send email to requester: Uses the current requester logic.

• Send email to agent group: Uses the current agent-group logic.

• Send email to {{anybody}}

  • If one user is selected: The email follows the logic described in Point 2 for approvals and journeys, as it is assumed that the recipient is either being assigned a task or being provided with relevant information.

  • If one non-Freshservice user is selected: The email uses the portal accessible to the requester of the underlying entity, as non-Freshservice users are not mapped to a portal.

  • If multiple users are selected: Since all recipients receive the same email, the URL and {{servicedesk name}} placeholder are resolved based on the portal accessible to the requester. If the requester is deleted or invalid, the system uses the oldest portal mapped to the workspace.

7. 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

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 portal name only in modules that support multi-portal awareness. For the modules listed in the previous point, it will resolve to the name of the default portal.