TABLE OF CONTENTS

• Supported plans and account modes
• Overview
• 1. URL resolution logic for email notifications
• 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 incident type tickets, check the originating portal: If the requester first reported the ticket through a portal, the ticket remains in a workspace mapped to that portal, and the requester still has access to it. Freshservice uses the originating portal’s URL in the email.

Currently, this behavior is supported only for incidents (that is, regular tickets), and not for service requests, changes, or journeys submitted via a portal.

3. Pick from the list: 

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

• If several are on the list, Freshservice picks the one 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

For notifications sent to multiple recipients in a single email, such as CC notifications or ticket-sharing notifications, a single portal is selected for the entire notification.

In these cases, the system first attempts to use the portal through which the requester submitted the request, provided the record still belongs to a workspace mapped to that portal. If that is not possible, the system selects a portal that is mapped to the record's workspace and is accessible to the requester.

This approach is based on the assumption that CC'd users and users with whom a ticket is shared 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.

For notifications that are always sent on a one-to-one basis, such as watcher notifications, the agent portal-selection logic is applied, since watchers are always agents.

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: When an agent replies to a ticket, any URLs included in the ticket reply template (template found in email notification settings) are generated using the requester portal-selection logic. The user taken into consideration for resolving the URL is the ticket’s requester.

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

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:

• Canned Responses

• 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:

  • Approval emails 

  • Document generation emails 

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

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

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.