page layout assignment permission set

• Salesforce Admin

Convert profile to permission sets in Salesforce.

• Nov 6, 2023

Join us for a Profiles to Permission Sets Journey. Join our Guide to Convert profile to permission sets in Salesforce. We will cover the different ways to migrate Salesforce Profiles to Permission Sets.

Why Convert Profile to Permission Sets in Salesforce?

Let’s understand Why this is important! To Converting Profiles to Permission Sets.

• Reduces time on Maintenance
• Aligned with Salesforce strategy
• Profiles are not scalable and flexible for future user growth.

What is happening to Permission Sets and Profiles?

Permission Sets and Permission set groups are the Future. Profiles are not going away, but permission on profiles will be GA after spring ’26. Profiles were phased out to permission sets, and now we need limited features on Profiles.

Learn more here .

How Do We Review Permissions With Existing

Review all profiles and user permissions with User access and permissions assistant .

• Leverage the security zen tool to export permissions to a spreadsheet for analysis.
• Identify standard permissions based on persona, users, and departments.
• Identify unique permissions
• Create Minimal permissions for profiles

Redesign your Security with 6 layered Approach

Redesign your Security with a layered Approach

• Foundation model
• Considerations
• User Provisioning
• Implementation

Model- Strategy on Permission Sets and Permission Set Groups

• For an existing Org that has profiles
• Redefine your personas based on departments or logical group
• Each persona will be a permission-set group
• Redefine permission sets based on job functions

Model- Key Principles for Security Redesign

• Create Personas based on job functions instead of departments
• Create permission sets for leadership
• Permission sets for bare minimal user
• Muting permission sets for excess permission
• Enhanced privileges
• Temporary users

Model- Strategy on Permission Sets – Object Based

This is for smaller orgs or Bu with less than ten objects

• E.g. Read Account
• Edit Account
• Delete Account
• System admins
• Interim consultants.
• Advanced Business Users or sme
• Provides a granular permission
• Highly flexible
• It can be cumbersome for objects of more than 10
• Will involve more test cases for testing

Model- Permission Set Strategy With 3-Set Approach

Model- Permission Set Strategy for Larger Orgs – 3 Set Approach

Global Enterprise Security Model

Converting Profiles to Permission Sets Considerations

Here are Converting Profiles to Permission Sets Considerations.

1. Current State Record Type and Page Layout

Page layout assignment exist only at profile level based on record type. On a profile object setting for the object opportunity, the default record type stays at the profile.

2. Current State Record Type Assignment

The permission set allows you to assign the record type.

3. Muting Permission Sets Considerations

• Permission set group – The permission set group includes all of the permissions in its included permission sets.
• The ability to include permission sets in more than one permission set group offers a lot of flexibility.
• What if the Requirement is – Don’t assign all the permissions in a permission set to users in a permission set group?
• Muting lets you customize a Permission set group by muting (disabling) selected permissions in it
• The phased rollout for a smooth transition and minimizes disruptions
• Keep record types minimum to simplify the data model

4. Considerations- Login hours and IP Ranges

• Currently, Login hours and IP range permissions are set at the Profile Level.
• Leverage connected apps to restrict external applications with IP and log in hours
• Leverage IDP to restrict permissions for location-based access control.

5. Privileged Access Principles

• Maintain permission set groups for system admins with enhanced permissions
• Interim consultants
• Mute modify all and delete all permissions for temporary access

6. Strategy On Profiles for Phase Out

• Consolidate the permissions across profiles and maintain a minimal Profiles – not to exceed 5
• Keep 1 profile for all users with minimal permissions
• Keep a profile for API-only users
• Keep a profile for system admins

7. Strategy on Permission sets – Community Users

• Setup baseline security with OWD using external access
• Leverage permission sets for authenticated users
• Keep a separate permission set for guest user
• Use the delegated admin feature for advanced guest users to manage their own accounts and contacts
• Watch out for guest users owning records and set default owner if needed

8. External Management for Users

• Account Switcher component: Allows external users the ability to access other accounts
• Ability to configure an external managed account to allow an external user to manage another account
• An external managed account designates a managing user, the target account that they can manage, and the type of access they’re authorized to on the target account
• That is in addition to administrators and internal users

9. Implementation Strategy

• Define Phases based on persona or department
• Have a backup strategy for rollback if needed
• Do the Owd to private before you do permission sets
• Ensure all public read-only and read-write are deployed in the initial roll-out
• Get SME for each persona to test our permissions
• Have mechanisms to track profiles, permission sets, and permission set group changes

10. Testing- Testing Strategy

• Identify test cases for each persona to be migrated
• Identify test cases for privileged access, like system admins
• Identify test cases for exclusive permissions or unique permissions
• Identify test cases for sensitive data access like PII, PCI or Payment information
• Apps on App Exchange
• Test classes to run common test cases

11. Security Audit

• Work with your CISO or Infosec on IT controls for logging permission requests.
• Identify default permissions for each persona and have an audit trail for requests, changes
• Monitor privileged access permissions
• Have a process for recertifications
• Leverage Identity governance tools for logging default permissions across each application.

Compliance – Monitor Permissions Proactively

Monitor Permissions with Security center . Track Permission changes on permission sets and permission set groups Monitor Malicious Apps.

Thanks, Abhinandana Gotam, Jason Norat, & Buyan Thyagarajan, for such a great session in Apexhours.

Related Posts

Lead Auto Response Rule in Salesforce

Suffixes in Salesforce

Best Practices for Migrating from Salesforce Enterprise to Professional Edition

Hi , Thanks this is useful information, i have one question first of all you need to tell this managed app with users does not understand

Leave a Reply Cancel Reply

Your email address will not be published. Required fields are marked *

Name  *

Email  *

Add Comment  *

Notify me of follow-up comments by email.

Notify me of new posts by email.

Post Comment

• Support Portals
• PRM Portals
• Member Portals
• Online Communities
• User Experience
• Accelerators
• AC Knowledge Management Enterprise 
• AC Events Enterprise
• AC Ideas Ultimate
• AC Partner Marketplace
• AC Partner Co-Branding
• AC eCommerce for Nonprofits
• AC Job Board
• AC B2B Commerce Recurring Orders
• AC MemberSmart
• AC Fundraising
• AC B2B Commerce OrderPad
• Higher Education
• Member Organizations
• Manufacturing
• IT\High-Tech
• Video library
• Success stories
• SI Partners

Book a demo

If you'd like to book a demo with us and see how our products work, please complete the form and we'll arrange a demo with you as soon as we can.

I agree to the Privacy Policy and Terms and Conditions

By submitting this form, you agree to occasionally receive guides, tips, and tricks from AC. You can unsubscribe at any time.

The Future of User Management in Salesforce: Switching From a Profile-Based Access Approach to Permission Sets

Salesforce has recently announced a significant change to the data access and user permission management, bringing a new era of user management in Salesforce. 

The company has reported the end-of-life (EOL) of permissions on profiles, which will take effect in the Spring ’26 release.

This article will explore the reasons behind this evolution, the future of profiles and permission sets, and provide you with information on what you can do now to prepare for the upcoming changes.

What exactly is happening and why?

If you’ve been staying up-to-date with the latest features for Salesforce admins, you might have noticed that Salesforce has been giving updates on the future of user management. For the last three years, Salesforce has been consistently talking about permission sets as the way forward for managing user access. The wait is over! Salesforce will be phasing out permissions on profiles, and these changes will be fully implemented in the Spring ’26 release.

Profiles will continue to exist, but the permissions that are currently assigned to profiles will be phased out and will only be available through permission sets. 

The limitations introduced to profile-based permissions will have a positive impact on user management in Salesforce, making it much easier for administrators to manage user access, maintain data security, and ensure safety.

What will remain on a profile:

• One-to-one relationships — login hours/IP ranges
• Defaults — record types, apps
• Page layout assignment — the future is App Builder/Dynamic Forms so Salesforce will not invest in bringing page layout assignment to permission sets

What will only be available on permission sets:

• User permissions (system and app permissions)
• Object permissions (object Create, Read, Update, and Delete)
• Field permissions (field-level security)
• Record types (not defaults)
• Apps (not defaults)
• Connected app access
• Apex classes
• Visualforce pages
• Custom permissions

Salesforce Experience Cloud as a Tool for Digital Transformation

Important notes to keep in mind now!

• In order to migrate user profiles to permission sets and permission set groups, use the User Access Policies feature that is currently in Closed Beta (as of Spring ’23).This feature allows you to specify criteria about your users to help you migrate them efficiently. To participate in the Closed Beta fill out the form .

• Salesforce has a new feature in Open Beta that allows you to set Field Level Security (FLS) on permission sets instead of profiles. You can activate this feature in the user management settings. Salesforce is planning to make this feature Generally Available (GA) in Summer ’23.
• Spring ’24 release will provide you with the opportunity to turn off the ability to use permissions on profiles before the official EOL.

Why we recommend our customers to switch to permission sets

The main idea behind it is to ensure managing users in the Salesforce Experience Cloud easier for companies and their Salesforce admins.

Profiles in Experience Cloud sites

Each user in Experience Cloud is assigned a profile. Salesforce admins formerly had to modify profiles manually or with the use of Flows in order to provide the user the proper access to data, which required a lot of time and effort. With permission sets, internal user management in Salesforce will become much easier. 

Product updates

We strongly recommend that our customers who use our custom Salesforce-native solutions on their Experience Cloud sites switch to using permission sets. Permission sets are a powerful tool that allow us to make feature updates and performance enhancements to our applications quickly and easily, without requiring any manual adjustments to access levels. Whenever we release a new version of our product, all updates are automatically applied to our customers’ orgs, including any necessary changes to permissions. This makes life easier for our customers, since they don’t need to worry about adjusting access by profiles or permission sets to specific objects or fields. By using permission sets, they can be sure that they always have the most up-to-date version of our software.

It’s time to stop the never-ending profile updates required for configuring access to your site and data. Switch to permission sets to easily manage community users and keep your site running smoothly, even when the products you’re using are updated.

Subscribe to our Newsletter

Receive regular updates on our latest blog posts, news, and exclusive content!

Looking for Assistance? Get a Helping Hand Here!

Change is in the air, taking user management in Salesforce to new heights. Don’t wait until the Spring ’26 release. Start your transition to permission sets right now!

To ensure the smoothest and most painless process, we recommend leaving this job to professionals. At Advanced Communities, we have a wealth of experience working with Salesforce and its products. Let us help you meet these changes fully armed and prepared for the new era of user management in Salesforce. 

If you’re looking for robust solutions for your Experience Cloud, such as event management solution, comprehensive Salesforce knowledge management tool , or member management app for Salesforce Experience Cloud , we’re here to help.

Need assistance with Salesforce online communities implementation ? Feel free to reach out at [email protected]

Meet us at AppExchange .

Rate the article

Salesforce World Tour NYC

June turned out to be rich in different activities, and we were honored not only to visit Salesforce World Tour in New York but to be a Gold Sponsor of one of the most anticipated events of the year! 

Lightning Article Editor & Article Personalization: Biggest Salesforce Knowledge Update

The Summer '23 release of Knowledge includes a beta release update with two new features: the Lightning Article Editor and Article Personalization for Knowledge. In this article, we'll dive into these features providing you with an overview of each of them and showing you how they streamline article management in Salesforce.

Salesforce Dreamforce ’23: Experience Cloud Highlights

Advanced Communities team is back home from Dreamforce 2023 full of positive energy and inspiration to move forward. In this article, we'd love to share with you the standout moments, with special attention given to the Experience Cloud, that made these three unforgettable days in San Francisco truly remarkable.

• App Building
• Be Release Ready – Spring ’24
• Integration
• Salesforce Well-Architected ↗
• See all products ↗
• Career Resources
• Essential Habits
• Salesforce Admin Skills Kit
• Salesforce Admin Enablement Kit

Home » Article » Best Practices for Configuring Your Integration User

Best Practices for Configuring Your Integration User

As a security-minded admin, you should follow the principle of least privilege. What is the principle of least privilege, you ask? It’s the concept of limiting users’ access rights to only what is required to do their jobs. That’s always been my guiding principle as an admin, and even when I was a customer. Following this principle does take discipline and patience.

If you’re using the Salesforce API Only System Integrations profile for the first time, I highly recommend you configure this in a sandbox before implementing in production. This is because you want to perform thorough testing in a safe environment before potentially negatively impacting your production data.

Note: Not all integrations work with this license. Check with the vendor/provider. You may not be able to assign a managed package permission set based on the permissions granted to the integration user.

Allocate one user per integration

The easiest way out when it comes to setting up access for a new integration is to use the System Administrator profile. Easy peasy. In fact, there have been several times in my career when trying to work with vendors on least privilege access for the integration user where their answer is to give system admin access. WRONG! When challenged, you’ll find that most of the time, the integration works just fine without giving the keys to the kingdom with the System Administrator profile. There was the rare occasion where the integration needed to be assigned to the System Administrator profile for the integration to work (it appeared they looked for the specific profile name on their end).

My recommendation: Start by establishing a new user for each integration, assigned to the Salesforce Integration user license. The Salesforce Integration user license creates the Salesforce API Only System Integrations profile and Salesforce API Integration permission set license available for assignment. Enterprise Edition, Unlimited Edition, and Professional orgs are automatically provisioned with five Salesforce Integration user licenses at no additional cost. If you need more licenses, reach out to your account executive (AE). API Only means the user can only access Salesforce via a REST , SOAP , or Bulk API and not through a user interface.

If you use the same user account across multiple integrations, you’re most likely opening an integration to have more access than needed, and thus, not adhering to least privilege access. It also minimizes security impact if the user or integration is compromised.

With a dedicated integration user, you can really lock down your integration to what it truly needs access to, including login IP ranges. Think about which permissions are necessary for its job to be done.

Under Company Information in Setup, you’ll find the Salesforce Integration under User Licenses and the Salesforce API Integration under Permission Set Licenses.

Here’s an example of an integration user assigned to the Salesforce Integration user license. Upon user license assignment, it populates the profile with Salesforce API Only System Integrations.

Once you verify the new account, rather than log you in to the org, Salesforce shows a note that access is restricted for API Only users. For all subsequent logins, the REST, SOAP, or Bulk API must then be used.

Remove permissions from the Salesforce API Only System Integrations profile

Given that permissions on profiles are slated for end of life in Spring ’26, the go-forward model for user access control is persona-based with use of permission sets and permission set groups. The profile should only be used to control defaults, page layout assignments, login hours and IP ranges, and the all-important API Only permission.

With this end goal in mind, I strongly recommend you edit your Salesforce API Only System Integrations profile and strip all permissions from the profile itself. Use permission sets and permission set groups to extend the other permissions, such as user permissions, object and field permissions, connected app access, and much more.

In an ideal world, you wouldn’t need to take this step. The Salesforce API Only System Integrations profile should be bare bones to start. Note: There’s currently a known issue with the Salesforce API Only System Integrations profile adding more permissions upon creation in the org.

Assign the Salesforce API Integration permission set license

Additionally, you will need to assign the Salesforce API Integration permission set license to your integration user. The Salesforce API Integration permission set license, in a nutshell, contains all the permissions you would find in the standard System Administrator profile that were lifted and moved to a permission set license instead.

What’s the difference between a permission set license and permission set? Think of a permission set license as additional permissions above and beyond the permissions already granted by your user license. A permission set is a subset of permissions granted to a user assigned to the permission set. If you assign users permissions via a permission set and they don’t have the required licenses, you receive an assignment error.

Let’s say Mochi (my pomeranian) is assigned to an animal user license that does not allow her to have zoomies and eat dog treats, but she needs to be able to have both. Mochi is assigned to a dog permission set license that gives her the ability to have zoomies and eat dog treats. However, for Mochi to actually have zoomies or eat dog treats, she needs the two permissions granted to her via a permission set.

In the case of our integration user, we have assigned it to the Salesforce Integration profile (user license), which only has the administrative permissions: API enabled, API only user, and Chatter internal user enabled. It has no access to standard or custom objects. To grant an integration user additional permissions needed, we extend the functionality access via the Salesforce API Integration permission set license. If you need to grant access to read and edit contact data, you would grant this access to the integration user via a permission set.

Note: When creating a permission set, when you select a specific permission set license, any user assigned to the permission set is auto-assigned the permission set license. If you select —None—, you must manually assign the permission set license to users before you can add them to the new permission set.

To view all the permissions associated to the Salesforce API Integration permission set license, locate the permission set license on the Company Information page in Setup. It will then take you to a page that lists all the permissions granted in this permission set license.

Exercise user management best practices to extend access

Follow the admin best practices for user management to grant the needed permissions to your integration users. Excluding your defaults (record types and apps), page layout assignments, and login hours and IP ranges, create permission sets and permission set groups to extend access to your integration users. Bundle permission sets into persona-based permission set groups for ease of user management. With permission set groups, you can reuse your permission sets and use the muting feature in the permission set group to remove permissions from permission sets that do not apply to the users assigned to the permission set group.

So, which permissions you should grant your integration users? Well, it depends. One integration may need Read/Edit access to your account and contact data. Another integration may need Read access to your user data as well as access to create activities. You’ll need to work with the integration provider to determine the least privilege access for that integration user. Check with the provider/vendor—they may have this information already documented in a setup/user guide.

Based on your use case, your integration user may also need additional permission set licenses, in addition to the Salesforce API Integration permission set license. If you run into an issue where you are unable to assign a specific permission set license, open a case with Salesforce Support indicating that you are unable to assign the specific permission set license to a user with the Salesforce Integration user license.

Test, test, test, and do more testing!

Before you make these changes in production, please do thorough testing of the new integration profile, permission sets, and permission set groups configuration in a sandbox to ensure all works as expected. Experiment first with the bare minimum privileges. As you do your testing and identify issues, add more permissions to your permission sets until your integration can fully do its job with the permissions you granted it. Yes, sometimes this will be trial and error.

Implement in production and monitor

Finally, implement the changes into production. Verify no new permissions snuck into the Salesforce API Only System Integrations profile during its deployment/implementation. If so, manually edit the profile to remove permissions that the profile you tested with did not have. Spend a month monitoring the integration to confirm it has the necessary permissions. if updates are necessary, make the changes to the permission sets/permission set groups in a sandbox, test them, and deploy the changes to production.

If you’re moving an existing user to the new integration profile, permission sets, and permission set groups access model, I recommend keeping the previous model in place, in case you need to switch back in a pinch and delete the obsolete access model (that is, custom profile/permission sets) after 1 to 2 months of the integration running fine on the new access model.

• Salesforce Help: Give Integration Users API Only Access
• Salesforce Admins Blog: Admin Best Practices for User Management
• Trailhead: Permission Set Groups
• Salesforce Architects Site: Authorization section of Well-Architected | Secure
• Salesforce Architects Site: Organizational Security Patterns and Anti-Patterns of Well-Architected | Secure
• External Site: YouTube: Salesforce Architects: What Not to Do on Salesforce
• External Site: Salesforce Ben: Salesforce Releases 5x Free Integration User Licenses
• Known Issue: Standard profile creation should not clone Custom Entity CRUD perms
• Known Issue: Allow editing custom entity perms on standard profiles

Jennifer W. Lee

Jennifer is a Lead Admin Evangelist at Salesforce and the host of our live streamed series Automate This! She is Flownatic, 8x certified Application Architect, Trailhead enthusiast, and Golden Hoodie recipient. Prior to joining Salesforce, Jen was a Koa customer, blogger (Jenwlee.com), founding co-host of Automation Hour, and a Salesforce MVP (2016-2021).

• Einstein for Formulas | Spring ’24
• Jen’s Top Spring ’24 Release Features
• How to Automatically Deactivate Users Who Haven’t Logged On in 90 Days
• What Is a Platform Event-Triggered Flow?

Related Posts

Introducing Invocable Composer Flows: Automate End-to-End Across All of Salesforce

By Tripti Assudani | July 31, 2023

What are Invocable Composer Flows? MuleSoft Composer is an integration tool designed for admins, business analysts, marketers, salespeople, and team leaders. Using Composer, you can quickly and easily build flows to integrate systems and data and automate integration tasks. It’s a no-code tool you can use to build automations with only clicks. To further supercharge […]

How to Configure Error Handling in MuleSoft Composer

By Sai Phang | June 26, 2023

MuleSoft Composer is the fastest and easiest way to connect apps and data for business teams, in partnership with IT. With the long-awaited error handling feature that Muleys are excited about, you can build more robust and resilient automation. You can further automate your flows, get real-time notifications on failures, mark failed records for reprocessing, […]

Integrations Are Easier Than Ever with Flow HTTP Callouts

By Marc Delurgio | June 19, 2023

Are you tired of waiting for IT resources to build out an integration to your supplier? Are you frustrated that your payroll system lacks reliable application programming interface (API) documentation, leaving your IT team to weed through JSON and just hoping it’ll work? Then Flow HTTP Callout is for you! This feature does the hard […]

• Things To Know Before Getting Started
• Creating Orgs, Connecting to Flosum and Adding Users
• Pulling Changes from Your Development Sandbox
• Version Control & Merging Changes
• Deploying Changes To Your Target Org
• Scheduling Deployment
• Rollbacks: Getting Started
• Comparing Orgs

Case Studies

Implementation guide.

• Request Flosum Upgrade
• Flosum for the Git Developer
• Archive a Branch
• Keeping Orgs in Sync with Repository Without a Refresh
• Deployment History
• Maintain Settings After Org Refresh
• Mass Delete Branches
• Set the From Address for Flosum Emails
• Installing Flosum
• Creating a Connected App
• Setting up Flosum Integration User
• Connecting sandboxes to Flosum
• For Government Cloud Customers
• Setting up users in Flosum
• Security Model in Flosum
• Initializing a Repository
• Setting up workflow permissions
• Pulling changes from dev sandboxes
• Branching Strategy
• Conflict and Merge strategy
• Peer Reviews
• Static Code Analysis
• Regression Testing
• Reference Architecture
• Post-install Steps
• Purging snapshots in Flosum
• Compliance & Governance
• Salesforce DX: Scratch Org Creation
• CI/CD & Pipelines
• Branch Updates in Flosum DevOps
• Pipeline Operations
• Deployment Dashboard
• Deployment Manager
• Domain Management
• Flosum-Slack Webhook
• Connecting Orgs to Flosum DevOps Using JWT Authentication
• Demerge Branch
• Multi-Domain Support for Multi-Git Integrations
• Multi Branch Merge
• Source Member Setup and Configuration
• Deploying Installed Packages
• Profile Retrieval on the Branch
• How to Abort a Running Apex Job
• Snapshot From Unlocked Package
• Snapshot Detail
• Flosum Dependency Identifier
• Branch Permissions Functionality
• Branches Tab
• Merge Process Approval
• Multi-file components edit
• Lightning Test Service
• Define Destructive changes in Branches in Flosum
• New Editor in Snapshot Comparison Screen
• Profile Comparison
• Pull Requests
• Create and Commit a Branch
• Destructive Changes
• Overwrite Protection Feature
• Pre-Deployment Fix
• Backsynch Process
• Advantages of Deployments
• Custom Validation Logic Before Deployments
• Test Execution During Deployments
• Scheduling Deployments
• Delete a Repository
• Download Components on Repository
• Committing Changes to the Repository
• Export Audit Trail Changes Recorded in Org
• Version Control Overview
• Getting Started with Version Control
• Audit Trail
• Settings Tab
• Org Details
• Org Permissions
• Salesforce Flosum Permission Sets
• Data Masking
• Orgs Tab Snapshot Comparison
• Flosum Metrics
• Kanban Board (Swim Lanes)
• Reports and Dashboards
• Branch State Diagram
• Getting Started with Vlocity in Flosum
• Supported Vlocity Components
• Vlocity Components
• Snapshot – Vlocity

Integrations

• Flosum-Provar Integration
• Heroku - Git Agent Integration
• Marketing Cloud Integration (Beta)
• B2C Commerce Cloud Integration (Beta)
• Flosum DevOps Architecture, Agents, and More
• Flosum Scan Integration
• Veeva Vault Integration
• Bitbucket on Cloud Environment Variables
• GitLab on Cloud Environment Variables
• Hyperforce and Flosum
• Flosum & Visual Studio
• Flosum Agent Architecture
• Agile Accelerator Integration
• Support for AccelQ Regression Testing Tool
• ServiceNow Integration
• Flosum & IntelliJ IDEA
• Unlocked Packages
• Flosum to VersionOne Integration
• How To Integrate Flosum With CodeScan
• Flosum Sandbox
• Source Code Analysis - Apex PMD (Code Quality)
• Flosum & Jira Cloud
• TFS/Azure DevOps
• Azure on Cloud Environment Variables
• Azure DevOps Pipeline Webhook
• Flosum’s Azure DevOps Story Integration
• Jira Webhooks to Flosum
• JIRA & PMD Upgrade
• Jira Webhooks Use Case
• Flosum’s On-Premise Jira Integration
• Requirements for Naming Branches and Repositories
• GitHub on Cloud Environment Variables
• Flosum – Git Version Control
• Source Member Tracking
• Partial Permission Set Deployment
• Demystifying Snapshot Retrieval Process In Flosum
• Demystifying Community Deployments Salesforce
• Understanding Salesforce Flow Deployment
• Demystifying Standard Component Deployments
• Demystifying Picklist Deployments
• Demystifying Profile Deployments
• Demystifying Lightning Pages And Components In Flosum
• Track Pending or Old Deployments
• Demystifying Record Type Deployments
• Demystifying Page/Search/Compact Layouts Deployments in Flosum
• Demystifying Translations Deployment In Flosum
• How to Retrieve Custom Metadata and Its Records in Flosum
• Deploying Custom Label Translations
• Deploying email-to-case via Flosum
• Demystifying Process Builder Deployments
• GlobalValueSet changes not being picked up
• ListView deployment failing
• Deploying Custom Metadata Records Using Flosum
• Including Reports and Email Templates in Snapshots
• Demystifying Einstein Components in Flosum
• Demystifying Deploying Public Groups
• Utilizing Flosum Agent for Metadata Retrieval
• Field History Tracking deployment
• Environment Variables
• Metadata API 52 Upgrade
• Metadata API 48 Upgrade
• Demystifying CustomObject Deployment In Flosum
• Demystifying Button, Links and Actions in Flosum
• Deploying FlexiPage Assignments
• Metadata Types retrievable only via zero day snapshot
• Metadata Component Types Supported by Flosum

Best Practice

• Sandbox Environments in ALM
• Code Coverage Check
• Purge Routine
• Optimizing your deployment
• Reducing Deployment Time With Flosum
• Improving your Governance Model
• Flosum-Git Folder Structure Rules
• Enabling MyDomain on your Flosum Org
• Updating your Callback URL
• Flosum's Retrieval & Deployment Webinar
• How to Grant Access to Flosum Support

Release Notes

• Flosum Updated Terminology - Winter 2021 Release
• Flosum DevOps 3.226 Release Notes
• Flosum Spring '21 Release Notes
• Flosum Summer '21 Release Notes
• Flosum DevOps 3.222 Release Notes
• Flosum DevOps 3.225 Release Notes
• Flosum DevOps 3.223 Release Notes
• Flosum Spring '24 Release Notes
• Flosum Spring '24 Data Migrator Release Notes
• Flosum Winter '22 Data Migrator Release Notes
• Flosum Winter '23 Release Notes
• Flosum Winter '24 Release Notes
• Flosum Winter '21 Release Notes
• Flosum Summer '23 Release Notes
• Metadata API Version 45 Upgrade
• Flosum Summer '20 Release Notes
• Flosum Winter '20 Release Notes
• Flosum Fall '19 Release Notes
• Flosum Spring '19 Release Notes
• Flosum Summer '21 Release Webinar
• Product Adoption Webinars
• Flosum Summer '23 Release Webinar
• Flosum Spring '24 Release Webinar
• Customer Training - Pull Requests
• Flosum Winter '23 Release Webinar
• Flosum Winter '24 Release Webinar
• Using Data Migrator Overlay Steps
• Customer Training – Merging Conflicts
• Winter 2021 Release Webinar
• Flosum's Spring Release Webinar 2021
• Business Continuity Plan
• Spring '20 Related Errors
• Flosum Pipelines: Winter 2020
• Webinar: 01/30/2020 - New Feature Overview, Pipeline Enhancements, Partial Rollbacks, Vlocity Components Support & More
• Flosum Refresher Training Webinar
• Webinar: Would You Like to Learn from Top Salesforce Professionals?
• Flosum's Summer 2020 Release Webinar

Data Migrator

• Data Migrator Frequently Asked Questions
• Migration of Product and Price Rules with Custom Conditions
• DM – Connect Your Organizations
• Support for Veeva
• nCino Integration
• Data Migrator Implementation User Guide
• Sequence Creation
• How to Give a User Access to Data Migrator
• Migrating the User Object
• Knowledge Article Migration Guide
• Data Migrator Proof of Concept
• Recursive relationships
• Field Level Security for Data Migrator
• Limitations of Data Migrator
• Best Practices for using Data Migrator
• Data Migrator Winter 2020 Release Notes
• Data Backup, Restore and Archive
• Security & Compliance
• Create a Salesforce API Limit Increase Request
• Implementation Best Practices
• Getting Started with DBR
• DBR Notifications
• Architecture, Prerequisites and Considerations
• Testing & Common Errors
• User Pool App
• Flosum User Pool SSO Setup with Google IDP
• Flosum User Pool SSO Setup with AWS Cognito
• Flosum User Pool SSO Setup with Azure Active Directory

Trust Center

• What is the Trust Center Solution?
• Install Trust Center
• Trust Center Post-installation Steps
• Schedule Trust Center Ops
• Install Flosum Agent Application
• Get Started with Trust Center
• Org Security Discover
• Org Security Dashboard
• Trust Center Org Security
• Trust Center Audit Trails
• Audit Trails Discover
• Audit Trails Dashboard
• Remediate Security Violations
• Trust Center Remediation
• Remediation Discover
• Remediation Dashboard
• Profile Security Template
• Organization Security Template
• Permission Security Template
• Trust Center Templates
• CRUD Report
• Metadata Reports
• Profile/Permission Set Comparison
• Data Dictionary
• Org Comparison
• Trust Center Data Masking
• Trust Center Data Masking Template
• Trust Center Data Masking Jobs
• Flosum Trust Center Settings
• Trust Center - Frequently Asked Questions

Org Scanner

• Org Security Scanner
• Flosum Release Management Frequently Asked Generic Questions
• Data Backup and Recovery Solution Frequently Asked Questions

Profile deployments have always been super painful in Salesforce. Flosum eases that issue to a great extent but there is still a lot of confusion on the nitty-gritties of profile deployments. This article deals with all the questions we have encountered over our years of experience. 

How do profiles work in Flosum?

RETRIEVAL – When Flosum retrieves a profile from the source org, the entire XML of the profile as published by Salesforce is retrieved.   Metadata API, however, does not return False values in some cases, only values marked as True.  Hence if you mark a value as False, it might not be retrieved and deployed. The details are below for each situation.  Note: Some Profile names are slightly different from the standard Salesforce Profile names.  For example:

StandardAul  = Standard Platform User

Standard  = standard user, marketingprofile  = marketing user, admin  = system administrator.

DEPLOY – On the Flosum Deployment screen, there is a setting – "Deploy profile settings only for components included in the deployment". This setting is checked by default. If your Deployment consists of Profiles and other components, then with this setting checked, the deployment will extract only the settings relevant to the other non-profile components in Deployment from all the profiles and deploy just those settings for each Profile. Let's explain this with an example. 

Say you have 3 profiles in your Deployment and among other things, each of them has the FLS settings for 2 custom fields in them. Suppose one of those custom fields is only part of the Deployment and not the other one. Then if the checkbox is checked when deploying, the FLS settings for only the custom field that is in the Deployment will be migrated to the target org, NOT of the custom field that is not in the Deployment. 

In the above scenario, if the checkbox on the Deployment screen was unchecked, then the FLS settings for both the custom fields would be deployed to the target org for all the 3 profiles. 

Salesforce does not change the Last Modified date of profiles even when it has been changed by an FLS change in a custom field for example. You might need to know its last modified date to pull it or use a 0-day snapshot. 

Component types that impact profiles

CUSTOM FIELDS – Field Level Security (FLS) for all fields is stored in profiles. So if you are deploying a custom field and want all its FLS settings to be deployed also, you need to deploy each of the profiles that have been given FLS settings for that custom field. Disabling profile access to a field can be deployed using Flosum . 

CUSTOM OBJECTS – CRUD settings for all objects are stored in profiles. So if you are deploying a custom object and want all its CRUD settings to be deployed also, you need to deploy each of the profiles that have been given CRUD settings for that custom object. Disabled CRUD settings can also be deployed (if all settings for an object are disabled, the Metadata API does not pick up the object at all and hence this scenario cannot be deployed). 

PAGE LAYOUTS – In order to deploy page layout assignments, you need to deploy the page layout, the record type it is associated with and the profiles together, if the checkbox "Deploy profile settings only for components included in the deployment" is checked. Just including the page layout and profiles only will not deploy the assignment if there is a record type dependency as well. 

If there is no record type dependency, then just deploying the page layout and the associated profiles will deploy the page layout assignments. 

RECORD TYPES – If you just deploy a record type without any of its associated profiles from the source org, this record type will not be available to any of the profiles in the target. Deploy the record type along with its associated profiles with the checkbox "Deploy profile settings only for components included in the deployment" checked and the record type will be available to the profiles as well. 

CUSTOM APP / CONNECTED APP – Deploy the Custom App along with its associated profiles with the checkbox "Deploy profile settings only for components included in the deployment" checked, and the Custom App will be available to the profiles as well. You cannot disable access to a custom app using Flosum due to Metadata API limitations. 

CUSTOM TAB – In the case of Custom Tab, the Off setting can also be migrated. So if the setting is set to Default On or Default Off or Tab Hidden, they can all be migrated if the Custom Tab and the relevant profiles are in the same Deployment and the checkbox "Deploy profile settings only for components included in the deployment" is checked. 

APEX CLASS / VISUALFORCE PAGE – For both classes and Visualforce pages, profile access can be granted and revoked. Keep the class or Visualforce page in the Deployment along with the relevant profiles. Doing the deployment with the "Deploy profile settings only for components included in the deployment" checkbox checked should allow to grant and revoke access both (Managed package class and Visualforce permission settings cannot be deployed). 

NAMED CREDENTIALS / EXTERNAL DATA SOURCE  –   For all these component types, profile access can be granted and revoked. Keep the component in the Deployment along with the relevant profiles. Doing the deployment with the checkbox "Deploy profile settings only for components included in the deployment" checked, should allow to grant and revoke access both. 

CUSTOM PERMISSIONS  –   In order to retrieve and deploy metadata components, we use the Salesforce metadata API. Salesforce Metadata API allows you to add existing custom permissions to profiles, but you cannot remove them. The behavior can be verified by using Workbench or another tool that uses the API. Several other users who have encountered the problem (unable to remove the custom permission set from the profile present in a Flosum DevOps branch) have manually executed these changes. FLEXIPAGE – Please refer to this   link . 

Deploying Administrative Permissions/General User Permissions

In order to deploy the settings in the Administrative Permissions/General User Permissions section of any profile, we have to deselect the "Deploy profile settings only for components included in the deployment" checkbox in the Deploy screen and have the profile as part of the Deployment. Doing this will deploy the profile as a whole.   False values cannot be deployed.  

Deploying IP Logins

In order to deploy the IP Login records of any profile, we have to deselect the "Deploy profile settings only for components included in the deployment" checkbox in the Deploy screen and have the profile as part of the Deployment. Doing this will deploy the profile as a whole.   Any IP login records in the profile in the target org that do not exist in the source profile will be deleted   and only the ones that exist in the source org profile will exist in the target org profile after deployment. 

Deploying Login Hours

To deploy the Login Hours associated with any profile, we have to deselect the "Deploy profile settings only for components included in the deployment" checkbox in the Deploy screen and have the profile as part of the Deployment. Doing this will deploy the profile as a whole including the login hours.  

Deploying Session Settings and Password Policies

To deploy session settings and password policies, use the "ProfilePasswordPolicy" and "ProfileSessionSetting" objects. The profile needs to exist in the target org but does not need to be part of the Deployment to deploy these settings. 

Deploying a brand new profile

If you need to deploy a brand new profile in its entirety, then please make sure to deselect the "Deploy profile settings only for components included in the deployment" checkbox if you do not want to include all the other components it references as part of the Deployment. This would be the most efficient way to deploy a new profile. 

Other Points 

If you check the "Deploy profile settings only for components included in the deployment" checkbox, only settings related to other components in the Deployment will be deployed. No other profile settings, even the ones not related to any component, will be deployed.

Profile Deployment Example 

1. Partial profile deployment: Profile exists in Target Org   Use Case: Developer has added changes to recordtype, custom fields, and Layouts and added them to the existing profile. In this case, we will use the Get Profile Feature: You will retrieve changes (recordtype, custom fields, Layouts) in a snapshot and commit to a branch. On the branch, you will see a lightning button known as "Get Profile" Use this get profile button to retrieve the profile where you have made these changes. In this case, it will retrieve only partial profile changes with respect to the components in your branch and then click on the deploy button. On the deployment page you will see a checkbox "Deploy profile settings only for components included in the branch" check this checkbox (by default it will be checked, so you don't have to do anything) and deploy to the target org. Document: https://success.flosum.com/s/article/Profile-Retrieval-on-the-Branch  

2. Full Profile Deployment: Profile does not exist in Target Org   Upon creating a new profile manually, Salesforce creates "App Permissions, Object Permissions, Apex classes, Visualforce pages, and some system permissions" by default and its a standard salesforce behaviour. As a result, you see discrepancies in the permissions of the source and target object profiles. Furthermore, we cannot disable these permissions using deployment since this is also standard Salesforce behaviour. The following steps should help you resolve this issue. This will be a one-time activity for new profile deployment. Steps: 1. Goto the Target Org. 2. Make a clone of any "Minimum Access - Salesforce" profile with the same name as the profile which you want to deploy from the source org. 3. Remove Read permission on 'Standard Object Permissions. 4. Make all tabs 'Default Off' on Tab Settings.

Note: When including profiles in a change set, it's important to review those profiles in the target environment after deployment as not all the permissions may carry over as you might expect. If object components are not included along with profiles, newly created profiles inherit the current object level access established in the license type's corresponding standard profile in the target organization. It's critical to review CRUD access to ensure newly created or deployed profile object level access in the target organization isn't greater than access set in the source organization. Some additional information:  https://help.salesforce.com/Deploy-Profiles-via-Change-Sets .

Product Area

Feature impact.

• What Is Trade Promotion Management?
• Get Started with Trade Promotion Management
• Main Objects in the Trade Promotion Management Data Model
• Master Data
• Main Objects in Customer Master
• Main Objects in Product Master
• Main Objects in User and Substitution
• Main Objects in Product Assortment
• Main Objects in Advanced Promotions
• Main Objects of Tactics
• Main Objects in Funds
• Main Objects in Rate-Based Funding (RBF)
• Main Objects in Multi-Fund Transactions
• Main Objects in Claims
• Enable Dynamic Streaming Channels
• Update Sharing Settings
• Enable Account Teams
• Enable Translation Workbench
• Enable Adding or Removing Apex Approval Process Locks
• Enable Chatter
• User Profiles
• Install TPM Package
• Post Upgrade Steps for Trade Promotion Management Winter ’24
• Ease Restrictions For New Business Years
• Edit Totals Derived From Past KPIs
• Verify Field Dependencies
• Patch Releases
• Import Additional Metadata

Permission Sets

• Activate Approval Processes
• Activate Flows
• Change the Page Layout Assignment
• Assign a Sales Org to a User
• Create a Self-Signed Certificate
• Register the Processing Service
• Download a Public Key
• Create a Connected App
• Complete the Pairing
• Configure User Access
• Replace the Certificate
• Considerations and Limitations for GCP
• Add the Tenant Substrate Field
• Enable GCP in Your Sales Organization
• Integrate Data From External Systems in GCP
• Clone a Data Source
• Page Layout Changes for Product and Assortment
• Download Add-Ons
• Install Salesforce CLI
• Deploy Reports
• Deploy Dashboards
• Assemble Batches Before Deploying Metadata
• Deploy Batches
• Log Out of Your Org
• View Claims
• View Multi-Fund Transactions
• Assign Managers for Users
• Create a Sales Organization Record
• Assign Users to the Sales Org
• Add the Sales Org Field to Search Layout
• Update Cache Allocation
• Enable Continuous Data Sync for Objects
• Configure TPM Calculation Chain
• Schedule an Apex Class
• Assign Custom Logo to the App
• Existing Retail Customer Upgrading to Trade Promotion Management
• Update Metadata Wizard
• Supported Languages
• Consumer Goods Release Calendar
• Learn About Migrating from Workflows to Flows
• Learn About Migrating from Process Builder to Flows
• Enable Downloads
• Limit Example: Promotion
• General Soft Limits
• Soft Limits of Account Plan
• Soft Limits of Promotion
• Soft Limits of Trade Calender
• Soft Limits of Funds
• Soft Limits of Rate-Based Fundings
• Soft Limits of Claims
• Soft Limits of Real-Time Reporting
• Create a Sales Organization
• Create a Business Year
• Create a Custom Calendar
• Extend a Custom Calendar
• Create a Weekday Share Profile
• Create Customer Templates
• Create a Customer
• Assign a Parent to a Customer
• Create Subaccounts
• Create a Customer Set
• Add a Customer Category Weekday Distribution Share Profiles
• Product Hierarchy
• Create a Product Template
• Add a Product Level to a Hierarchy
• Change the Product Level Order in a Hierarchy
• Translate the Product Level Picklist Labels
• Create a Product
• Assign a Parent to a Product
• Define a Unit of Measure for a Product
• Create a Bill of Material
• Assign a Product Manager to a Product
• Import Data by Using MuleSoft Direct
• User Personas
• Trade Promotion Management Permission Set Licenses
• Add Users to a Sales Organization
• Create User Settings
• Set Up Global Product Lists
• Set Up Time-Dependent Product Lists
• Create a Product Assortment Template
• Create a Custom Page for Product Assortment Grid
• Customize the Product Assortment Grid
• Create Product Assortments
• Manually Initiate Sync
• Schedule a Sync Process
• Schedule Server Processes
• Types of KPI Definitions
• Other KPIs References In a Formula
• Calculation Helper Functions In a Formula
• Referencing Variables
• KPIs in Real-Time Reports
• How Subperiod Values Are Stored for Writeback KPIs
• Create Validation KPIs
• Sample KPI Set JSON
• Create KPI Sets
• Create Compound KPIs
• Create KPI Maps
• Create a Field to Store a KPI Value
• Translate KPI Labels in Promotion and Tactic Objects
• Create a Fund Template
• Create a Fund
• Create a Rate-Based Fund Template
• Create a Rate-Based Fund
• Submit a Rate-Based Funding for Approval
• Stop Transactions on Rate-Based Funding Records
• Distribute a Rate-Based Fund
• Override a Distributed Rate-Based Fund
• Create a Fund Transaction Template
• Create a Multi-Fund Transaction
• Approve a Fund Transaction
• Overspending Funds
• Download an Account Plan P&L
• Set Up an Account Plan
• Create an Account Plan View
• Account Plan Filters
• Calculation of Account Plans
• Create a Customer Business Plan
• Edit a Customer Business Plan
• Create a Scenario
• Copy a Scenario
• Compare Scenarios
• Activate a Scenario
• Download a Scenario
• Multi-Level Promotion Planning (MLPP)
• Mega Events
• Create a Promotion Template
• Assign a Tactic Template to a Promotion Template
• Update the Product Filter Cache
• Create a Tactic Template
• Assign a Promotion Template to a Tactic Template
• Assign a Fund Template to a Tactic Template
• View Tactic Product Conditions
• Error and Exception Handling during Fund Auto-Determination
• Create Condition Templates
• Add Product Conditions
• Create a Condition Search Group
• Create a Condition Search Rule
• Condition Search Based on Account and Product Dimensions
• Condition Search for Collection Search Type
• Condition Search for First Hit Search Type
• Distribution of Lump Sum Conditions
• Product Hierarchy Conditions
• Example of Tactic Product Conditions
• Rate-Based Funding Conditions
• Assign a Child Promotion Template to a Promotion Template
• Promotion P&L View Configuration
• Volume Planning Card Configuration
• Spend Planning Card Configuration
• Scenario Planning Card Configuration
• Use Filters to Add Products
• View the Volume Planning Card
• View the Spend Planning Card 
• Tactic Funds Card
• View the Scenario Planning Card
• See the Promotion P&L View
• Sub Accounts Cards
• Promotion Filter Variables
• Run Your Batch Processes
• Configure Your Batch Processes
• Schedule Your Batch Processes
• View the Status of Your Batch Run
• Create a Multi-Level Promotion Plan
• Long-Term Agreements
• Determine the User or User Group with Access to Product Categories
• Determine the Promotion Categories Assigned to the Promotion
• Determine the User or User Group with Access to Promotion Categories
• Grant Promotion Access to the User or User Group
• Fields that Support Promotion Sharing
• Apex Sharing Rules
• User Permission Sets and Access
• Install the Promotion Sharing Add-On
• Considerations for Promotion Transfer
• Transfer a Promotion with a Tactic
• Transfer a Promotion with Tactic and Tactic Products
• Add Files in the Related List for a TPM Promotion
• Batch Processing
• Deletion of a Transferred Promotion
• Promotion Integration Configuration Fields
• Promotion Transfer Relevant Fields
• Create Business Object APIs
• Create the Business Object API Entity
• Create Business Object API Workflows
• Create Business Object API Workflow Steps
• Core Business Object API Rule Definitions
• Business Object API Transaction Log
• Understanding How KPIs are Calculated when Tactic Costs are Updated...
• Repush Promotions
• Create a Promotion
• Derive a Promotion
• Delete a Promotion
• Freeze and Unfreeze Promotions
• Mass Copy Promotions
• Add a Fund to a Tactic
• Fund Auto-Determination
• Prevent a Promotion from Being Deleted
• Translate Promotion Breadcrumbs for Building Blocks
• Key Functions and Elements of Trade Calendar View
• List View Controls
• Group Promotions and Events in the Trade Calendar View
• Define Your Trade Calendar View
• Change Color Using Promotion Templates
• Add New Phase for a Promotion
• Define Colors for Picklist Value Sets
• Assign Colors for New Picklist Values
• Add a Field to Promotion
• Add Promotion Color Filters
• Assign Colors for the New Field Values
• Licenses and Permissions for TPM Revenue Prediction
• Considerations Before Predicting Uplift
• Create a KPI Definition for a KPI Set
• Configure Tactic Templates for Uplift
• Prepare and Upload External Data
• Input Entities and Fields
• Input Features
• Apply Security Predicate to Your Datasets
• Forecasted Baseline Sales Dashboard
• Before You Begin
• Create Forecast Baseline Dataset Externally
• Create and Upload a Model
• Use the Deployed External Model in the Existing TPO Flow
• View Prediction Payload for Troubleshooting
• CRM Analytics App Assets
• Create a CRM Analytics Template Configuration
• Configure Amazon S3
• Predict Uplift in a Promotion
• Create a Claim Template
• Create a Claim
• Edit Tactic Payouts
• Combine Claims
• Link Claims
• Unlink Claims
• Submit Claims for Approval
• Adjust Claims
• Claim Calculations
• Add Filters to the Link Tactics Grid
• Components of a Real-Time Report
• Design KPIs
• JSON for Report Dimension
• JSON for Report Metadata
• Properties of a Filter
• Components of UIMapping
• Account Category Report
• Account Monthly Report
• Account Weekly Report
• Promotion Report
• Promotion Tactic Report
• Payment Report
• Fund Report
• Create a Lightning App Page
• Embed Reports on Promotion Record Page
• Export a Report
• Create a Account Report
• Create a Account Monthly View
• Create a Promotion Report
• Create a Promotion Tactic Report
• Create a Payment Report
• Create a Report to Compare Volumes
• Data Extraction for Third-Party Systems
• Examples How Total Value of KPIs are Calculated
• Examples of Calculating Cumulative Values
• Example of Aggregating KPI Values
• Understanding How Helper Functions Calculate KPIs
• Example: Calculating KPI Values from Sub Accounts
• Understanding How KPI Values are Calculated for a Promotion or Tactic
• Understanding How KPI Values are Stored when BOM Component is...
• BOM Scope for Calculated KPIs
• BOM Scope for Read KPIs
• BOM Scope for Editable KPIs
• Understanding How Daily KPI Values are Calculated
• Example: Values in Custom Calendar
• Example: Values for Custom Periods
• Special Case
• Determination of Prior Year Values with Year Offset
• Determination of Prior Year Values with Week Offset
• Determination of Previous-Year Values from Writeback Tables
• Determination of Previous-Year Values from Weekly Measure Tables
• Example: Referencing Other KPIs of the Same Granularity
• Example: Referencing Other KPIs of Different Granularity
• Example: Referencing Total Values of Other KPIs with Different...
• Example: Referencing Variables
• Example: Calculating KPIs of Subperiod Time Granularity
• Understanding How KPI Timeframe is Determined
• Examples: KPI Value Distribution
• Examples: KPI Value Distribution Based on Time Granularity
• Understanding How KPIs are Distributed Based on Lump Sum Conditions
• Examples: Promotion Border Correction
• Special Cases
• Example: Value Type Volume, Money, and None
• Example: Value Type Price and %
• Example: Period Then Sub Periods
• Example: Sub Period Then Period
• Understanding How KPIs are Calculated based on Week Day Share Profile
• Understanding How KPI Values are Determined Using KPI Maps
• Example of Field Set Assignment for Sales Orgs
• Maintain Columns in Manage Products Card
• Make Product Fields Searchable on Product Grid
• Maintain Product Fields in Calculation Grids
• Automatically Expand Calculation Grid Rows While a Component Loads
• Customize the Promotion Drilldown Component
• Licenses and Permissions
• Considerations for Setting Up Trade Promotion Effectiveness
• Set Up Trade Promotion Effectiveness
• Recipe in Trade Promotion Effectiveness
• Embed Analytics for Trade Promotion Effectiveness
• Create Other Versions of Trade Promotion Effectiveness
• MuleSoft Accelerator for Consumer Goods
• Salesforce CRM Analytics Connector
• Spend and Tactic Analysis Dashboard
• Volume Analysis Dashboard
• Embedded Dashboards
• Key Performance Indicators
• Frequently Asked Questions

Use permissions sets to give users access to specific features and functions without altering the existing profiles of the users.

Required Editions

Before you assign a predefined permission set, we recommend that you clone the permission set to avoid overwriting the permission set during a migration. You can assign predefined permission sets to:

• Administrators: Admin permission sets enable the setup and maintenance of the TPM app. The permissions don’t include customizations via Apex code.
• Users: User permission sets give user permissions based on predefined user types, ensuring that users have the access required to perform their specific roles and responsibilities within the org.
• Worker processes: Worker permission sets provide batch users access to run a CG Cloud Processing Services worker process.

Cookie Consent Manager

General information, required cookies, functional cookies, advertising cookies.

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings. Privacy Statement

Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.

Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.

Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.

Cookie List

• Marketing Cloud

Experiences

Access Trailhead, your Trailblazer profile, community, learning, original series, events, support, and more.

Search Tips:

• Please consider misspellings
• Try different search keywords

Assign Custom Record Types in Permission Sets

• From Setup, in the Quick Find box, enter Permission Sets , and then select Permission Sets .
• Select a permission set, or create one.
• On the permission set overview page, click Object Settings , then click the object you want.
• Click Edit .
• Select the record types you want to assign to this permission set.
• Click Save .
• How Is Record Type Access Specified? Assign record types to users in their profiles or permission sets (or permission set groups), or a combination of these. Record type assignment behaves differently in profiles and permission sets.