Controlling Access

Before rolling Datatrax out to end users, understand how permissions work across both systems — and how to scope access so users can only do what you've deliberately allowed.

How authority flows through Datatrax

Datatrax operates as two separate layers of authority, and it's important to understand both.

Layer 1: Salesforce

Controls who can create a Data Load Request, which operations they can select, and which mapping templates they can use. Standard Salesforce profiles, permission sets, and field-level security all apply here.

Layer 2: The connected user

Controls what Datatrax can actually do in Salesforce. All Bulk API calls — inserts, updates, upserts, deletes — execute under the credentials of the user who authorized the connection in the Datatrax portal Settings page. That user's profile and permissions are the ceiling for every load job, regardless of who submitted the request.

The connected user's permissions apply to all jobs. If a user with limited Salesforce access submits a load request targeting an object or operation they wouldn't normally be allowed to touch, Datatrax will still execute it — as long as the connected user has permission. Design your connected user's access deliberately.

Use a dedicated service account as the connected user

The user who connects your org in the Datatrax portal Settings page becomes the identity behind every API call Datatrax makes. Do not use a personal admin account for this.

Create a dedicated Salesforce user — something like datatrax@yourcompany.com — specifically for this integration.
Assign it a profile and permission sets that grant access to exactly the objects and operations Datatrax needs. If Datatrax should never delete Accounts, make sure this user can't delete Accounts.
Use this user to authorize the Salesforce connection in the Datatrax portal. All future jobs will run under this identity.

This approach has two benefits: the service account can be audited and its permissions adjusted independently of any individual admin, and if the account is ever deactivated the connection breaks in a visible way rather than silently running under the wrong identity.

Control who can submit load requests

The Datatrax User permission set grants access to the Data Load Request and Data Load Mapping objects. Assign it only to users who should be submitting load jobs. Users without it won't see the Datatrax app or objects at all.

The Datatrax Admin permission set additionally allows creating and modifying Data Load Mapping templates. Keep this one restricted to the people responsible for defining approved mappings.

Use mapping templates as your access control gate

This is the most important lever you have. A mapping template locks in three things: the target object, the operation (Insert/Update/Upsert/Delete), and the field set. Users can only submit requests that reference an existing, active template — they cannot freely choose an object and operation themselves.

This means your mapping library is your allowlist. Some practical patterns:

Separate templates by operation risk. Create distinct templates for Insert vs. Delete operations on the same object. This makes it easy to grant Insert access broadly while keeping Delete templates tightly controlled — or to deactivate a Delete template during sensitive periods without affecting Insert jobs.
Name templates to signal intent. A name like Account_Update_AddressOnly is self-documenting and limits scope — the field set in that template will only include address fields, so even if a user submits a request with it, other fields on the record are untouched.
Use the Active checkbox as a circuit breaker. If you need to temporarily block a particular load type — say, all Contact deletes — deactivate the relevant mapping. Any in-flight request referencing it will fail with a clear error. Reactivate when ready.
Never create a catch-all mapping. Avoid templates that map every field on a large object. Narrow templates limit blast radius if a user uploads a malformed file.

Restrict operations by profile or permission set

If you want to prevent certain users from even selecting specific operations on the Data Load Request form, use Salesforce picklist value set restrictions or validation rules:

Validation rule approach: Add a validation rule on Data_Load_Request__c that fires when a restricted user selects Delete or Upsert. Example: AND($Profile.Name = "Standard User", ISPICKVAL(Operation__c, "Delete")) — this blocks standard users from saving a Delete request entirely.
Field-level security: If certain user groups should never see the Operation field at all, hide it via field-level security on their profile and pre-populate it through the mapping template name convention instead.

Audit and monitor

Every data load is recorded as a Data Load Request record in Salesforce, with the submitting user captured in the Submitted By field. Use Salesforce reports and list views on Data Load Requests to monitor activity — filter by user, operation, status, or date to spot unexpected usage patterns.

On the Datatrax side, the Jobs page in your portal shows every job processed for your org, including which mapping template was used and how many records succeeded or failed.

← Submit Your First Load