Permissions

Forge has its own role system, layered on top of whatever your Salesforce profile and permission sets already allow. Both apply: Forge's own role decides which Forge features and admin surfaces you can reach, and Salesforce's own object/field permissions still decide which underlying records and fields you can read or write.

Forge's own roles: Planner, Admin, and Custom

Every Forge user has a role stored in Forge itself, shown as "Planner" or "Admin" on the admin Users page (Admin > Users): Admin can reach every admin-only surface listed below; Planner can build and manage events but not the org-wide admin configuration; Custom is a narrower role an Admin can define with specific permissions per navigation area (read/write per section). This role is independent of your Salesforce profile after it's first set — Forge does not re-check Salesforce on every login and silently reassign you.

The FIRST time a brand-new Salesforce user logs into a tenant, Forge looks at real signals from that user's Salesforce profile and permission set assignments (for example, the System Administrator profile) to suggest a starting role — this promotes a genuinely-privileged Salesforce user to Forge Admin, but it never demotes anyone and never changes an existing user's role on a later login. From then on, an existing Forge Admin manages every user's role directly on the Users page, the same way you'd manage any other setting in Forge — this is Forge's own role management interface, not a mirror of Salesforce.

How Salesforce permissions flow into Forge

When Forge reads or writes a Salesforce record, it does so using the authenticated user's Salesforce session. Salesforce enforces object-level CRUD permissions and field-level security (FLS) on every operation. If a user's Salesforce profile does not allow Read access to conference360__Attendee__c, they will not see the Attendees tab in Forge.

Blackthorn permission sets

Blackthorn provides managed permission sets that grant the minimum necessary access to the managed-package objects:

• Blackthorn Events Admin — full CRUD on all conference360__ objects. Intended for event administrators and Salesforce Admins.
• Blackthorn Events User — read/create/edit access for day-to-day event management. Cannot delete records or change gateway settings.
• Blackthorn Payments Admin — full CRUD on bt_stripe__ objects. Required for gateway configuration and refund processing.
• Blackthorn Payments User — read access to transactions and fees. Cannot issue refunds or change gateway settings.

Field-level security

If a Salesforce field is hidden from a user via FLS, that field will not appear in Forge — either in the UI or in exports. This is intentional and is how Forge enforces data governance. For example, if your FLS policy hides Contact.Email from a user, they will not see attendee email addresses in the Attendees tab. Forge re-checks the real, requesting user's own FLS on every write to a Salesforce field — not just a shared integration connection's schema access — so a field your Salesforce profile blocks you from editing there stays blocked in Forge too.

Sharing rules

Salesforce sharing rules also apply. If your org uses organization-wide defaults (OWD) that restrict access to certain conference360__ records, those restrictions propagate through Forge. Users will only see events, attendees, and transactions that their Salesforce sharing configuration permits.

Admin-only features in Forge

Some Forge features are restricted to users with the Forge Admin role (see "Forge's own roles" above) — this is Forge's own gate, separate from any Salesforce permission set. A few examples out of everything under Admin in the sidebar:

• Users & roles — inviting users and setting each one's Planner/Admin/Custom role.
• Payment gateway configuration.
• Org-level fee management.
• Beta feature opt-in (/beta page).
• Email provider configuration.
• Org settings and object-mapping configuration.
• Campaign sync and registration sync configuration.
• Admin audit log.