Managing User Access with Permission Sets

Permission sets are part of the underlying Salesforce platform. Permission sets for the full feature set of FinancialForce Accounting are provided with the managed package. You are advised to use permission sets instead of user profiles to manage your users' privileges. You can assign permission sets to up to 1000 users at a time.

From FinancialForce Accounting V13 onwards, predefined permission sets are provided for all new functionality so that you can easily give users access to new features. See Permission Sets Mapping to Profiles for a list of which permission sets correspond to each of these user profiles.

Identifying the FinancialForce Accounting Permission Sets

The FinancialForce Accounting permission sets have been designed in three levels. The three levels are: Application - Process - Action

This Application - Process - Action pattern is used as the naming convention for all FinancialForce Accounting permission sets. For example, the permission sets to create a sales invoice are available at the following levels: Accounting and Billing - Sales Invoice - Save. We recommend that you usually assign permission sets at Level 1 (Application) or Level 2 (Process), and only assign permission sets at Level 3 (Action) when absolutely necessary.

The following examples illustrate how you might want to assign permission sets at Level 1, Level 2 or Level 3 depending on your business needs:

  • In a small business with one accountant you might assign that user permissions for the whole Accounting and Billing applications so that they can access all processes in the applications and perform all actions. In this scenario you are assigning permissions at the Application level (Level 1).
    Note:

    To give a user full access to FinancialForce Accounting you must assign two Level 1 permission sets to him: Accounting and Billing (containing permissions shared by both the Accounting and Billing apps) and Accounting (containing additional permissions specific to the Accounting app).

  • In a medium-sized business with separate Accounts Receivable and Accounts Payable Managers, you might assign the Accounts Receivable Manager permissions to just the Sales Invoice and Sales Credit Note processes so that they can perform all actions for sales documents but not for other document types. Similarly you might assign the Accounts Payable Manager permissions to just the Payable Invoice and Payable Credit Note processes so that they can perform all actions for payable documents but not for other document types. In this scenario you are assigning permissions at the Process level (Level 2).
  • In a large business, to ensure separation of duties you might give the Accounts Receivable Clerk permissions to just the Save action for sales invoices so that they have the ability to create and save a sales invoice but cannot perform other actions such as post or discard. Permission to perform those actions might be restricted to the Accounts Receivable Manager only. In this scenario you are assigning permissions at the Action level (Level 3).

Each permission set gives the user access to everything they need to work with that application, process, or action. For example, the Billing - Sales Invoice - Save permission set includes READ and CREATE permissions for Sales Invoice and Sales Invoice Line Item, and READ permission only for other objects that are required to create and save a sales invoice such as Accounting Currency, Bank Account, General Ledger Account, Year and Period. A permission set also includes access to any classes and pages that are required to work with an application, process, or action.

Some more examples of the three tier naming convention are shown in this table:

Level 1 Level 2 Level 3
Accounting and Billing Accounting and Billing - Sales Invoice  
    Accounting and Billing - Sales Invoice - Amend
    Accounting and Billing - Sales Invoice - Discard
    Accounting and Billing - Sales Invoice - Edit
    Accounting and Billing - Sales Invoice - Post
    Accounting and Billing - Sales Invoice - Save
Accounting Accounting - Cash Entry  
    Accounting - Cash Entry - Amend
    Accounting - Cash Entry - Cancel
    Accounting - Cash Entry - Discard
    Accounting - Cash Entry - Edit
    Accounting - Cash Entry - Post
    Accounting - Cash Entry - Post & Match
    Accounting - Cash Entry - Save
  Accounting - Cash Matching  
    Accounting - Cash Matching - Match
    Accounting - Cash Matching - Undo

Permission sets for read-only access exist at Level 1 and Level 2 of the hierarchy. So you could give a user read access to the whole Cash Entry process for example, but only write access to the Save action.

Note:

Permission sets controlling access to apps and standard Salesforce objects (such as Account and Opportunity) are provided in a separate package which is installed as part of the onboarding process. You must assign the Billing - App, Accounting - App, and Accounting and Billing - Standard permission sets to users unless you already manage access to apps and standard objects differently, for example through profiles.

Permission Sets for Action Views

There are three groups of permission sets relating to Action Views. The Level 1 permission sets for these three groups are:

  • Action Views Accounting - the original permission sets for using the Action Views functionality within FinancialForce Accounting. These must only be used by customers who have not migrated their action views data to FinancialForce Reporting.
  • Action Views Reporting - equivalent to Action Views Accounting but for using the Action Views functionality within FinancialForce Reporting.
  • Action Views Reporting Integration - permission sets relating to the FinancialForce Accounting integration with FinancialForce Reporting.

Using the FinancialForce Accounting Permission Sets

Typically you might use a combination of user profiles and permission sets to manage your users' privileges. For example:

  • Use profiles to manage user privileges for standard Salesforce objects and other applications (excluding FinancialForce Accounting). Then assign the FinancialForce Accounting permission sets to your individual users.
  • Use profiles to manage user privileges for other FinancialForce applications such as PSA, but use permission sets for FinancialForce Accounting.
  • Use profiles to manage team-wide privileges, and permission sets to assign extra privileges to one or two individuals within the team.

Note that you cannot edit the predefined permission sets but you can clone them to create your own variations. If you create your own permission sets, you are advised to follow the three tier structure described above to avoid confusion. If you clone the predefined permission sets or create your own, you will need to manually update them to add new functionality in future versions of FinancialForce Accounting. The predefined permission sets will be updated automatically.

Note:

Once you are ready to go live with using permission sets, you must deselect the Disable Permissions on Visualforce Pages custom setting (Accounting Settings). Users will then have access to buttons on Visualforce pages only if their permission sets allow.

Migrating to using the FinancialForce Accounting Permission Sets

If you are upgrading from an earlier version of FinancialForce Accounting, here are some suggestions as to how you can migrate to using permission sets:

  • Continue to use your existing user profiles and assign permission sets to users for new functionality only.
  • Remove all FinancialForce Accounting permissions from your existing user profiles, then assign permission sets to users for all the functionality they need.
  • When creating new users, use a profile to manage user privileges for standard Salesforce objects and assign the FinancialForce Accounting permission sets to individual users.

You might want to create list views for groups of FinancialForce Accounting permission sets to make them easier to assign to users. For information about how to assign permission sets to users, see the Salesforce Help topics suggested below.

Adding Custom Fields to Permission Sets

If you add custom fields to any FinancialForce Accounting objects, we advise that you create one permission set to manage access to all of them. You could name the permission set Accounting and Billing - Custom Fields.

For example, if you add a custom field to the Sales Invoice object and you want users to be able to save sales invoices with this field populated, you will need to enable Read and Edit permissions for this field in your Accounting and Billing - Custom Fields permission set. You will also need to make the field available on the appropriate page layouts.

More Information

For more information about permission sets and how to assign them to users, see the Salesforce Help. Some useful topics to start with are:
"What are permission sets?"
"About Permission Sets and Profile Settings in Packages"
"Assign Permission Sets to a Single User"
"Assign a Permission Set to Multiple Users"