Grant Email Opt Out access on install without cloning the permission set

Open
  • Is something wrong?
#244 4 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@RubenHalman is already working on this.

Since Oct 20, 2026.

  • #245 by @RubenHalman — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Domain
backend

Research direction

Start by reading the package’s post-install setup and permission set metadata, especially Unsubscribe_Link.permissionset-meta.xml; the issue does not name specific script or test files. Implement the described install and upgrade behavior, including creating the subscriber-owned set and assigning it only on fresh installs. Done means the local set has the specified field permissions, fresh installs assign both sets to the stated users, and upgrades create a missing set without reassigning it.

Written by the indexing model from the issue text.

Description

Problem

The install guide tells admins to clone the Unsubscribe Link permission set, add read and edit on Email Opt Out for Contact and Lead, and assign the clone. That step is there because a managed package cannot carry those permissions.

Unsubscribe_Link.permissionset-meta.xml already includes Contact.HasOptedOutOfEmail, Lead.HasOptedOutOfEmail, and Contact and Lead object read/edit. On install, Salesforce drops standard object permissions and standard field permissions. The packaged permission set is locked, so the subscriber cannot edit it. Install for Admins Only does not assign the permission set, and it does not grant Email Opt Out.

Approach

Add a post-install script that:

  1. Creates a subscriber-owned permission set, Unsubscribe Link Email Opt Out (Unsubscribe_Link_Email_Opt_Out), with read and edit on Contact.HasOptedOutOfEmail and Lead.HasOptedOutOfEmail.
  2. On a fresh install, assigns that set and the packaged Unsubscribe Link permission set to the installing user and to every active user on the System Administrator profile.
  3. On an upgrade, creates the local set if it is missing, and does not assign it. Assigning again would undo an admin who removed it from a user.

The local set does not grant Contact or Lead object access. People who send email already have those objects on their profile. Object edit on this set would turn a read-only profile into an edit profile.

Other email senders are still assigned by hand. They get both permission sets. There is no clone and no field edit.

If the subscriber already has a permission set named Unsubscribe_Link_Email_Opt_Out with a different description, the script leaves that set alone.

Limits

  • Only the standard profile name "System Administrator" is treated as an admin. A cloned admin profile is included only when that user is the installer. In a translated org the English profile name may not match, so only the installer is assigned.
  • This starts with the next package version. An org that already installed the package gets the local set on upgrade, and an admin assigns it once.
  • The wiki section "Clone, Edit and Assign Permission Set" needs a follow-up in the wiki repo.

Out of scope

Putting Email Opt Out on the packaged permission set, or assigning a permission set to a profile. The platform does not support either one.

Dominant language
Apex
Stars
9
Forks
22
Avg merge
2d 22h
Merged PRs (30d)
3

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SFDO-Community/UnsubscribeLink

All issues in SFDO-Community/UnsubscribeLink

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.