How should security teams govern low-code app and dashboard creation on Salesforce platforms?

Security teams should treat low-code development as a governance problem, not just a usability feature. They need inventory, access review, and configuration controls for every custom app, report, dashboard, and automation. Platform-level controls such as MFA are necessary but not sufficient because they do not understand each build’s business logic or data exposure paths.

Governing Low-Code Creation as a Platform Security Problem

Salesforce low-code development is easiest to secure when teams treat every app, report, dashboard, flow, and integration point as a governed asset with an owner, a business purpose, and a data boundary. The practical question is not whether users can build, but whether the build is inventoryable, reviewable, and constrained to the minimum data and actions it actually needs.

That means governance has to start with discovery. Security teams need to know what was created, who created it, which objects and fields it touches, and whether it exposes records beyond the creator’s normal role. Without that inventory, platform permissions can look acceptable while the actual app logic still creates new paths to sensitive data.

Low-code also changes the usual control model because the risk often sits in configuration rather than code. A dashboard can surface privileged data to the wrong audience, a flow can automate an unintended action, and a custom app can become a shadow business process that never passed through formal review. The security team therefore needs to review build intent, data access, and sharing behavior together, not separately.

Require registration of each custom build before production use.
Map the objects, fields, and report sources each build can reach.
Assign a business owner who can approve purpose and access scope.
Review changes to automations and dashboards as part of change control, not as informal admin tweaks.

Controls That Matter More Than Platform Authentication Alone

Platform-level controls such as MFA and SSO are necessary, but they do not answer the governance question of what a build is allowed to do once a user is inside Salesforce. That is why access review, configuration review, and least-privilege design must extend to the low-code artifact itself, including the permissions that allow a builder to create, publish, or expose content.

Security teams should focus on whether the build respects role boundaries and whether its data paths are consistent with the user population it serves. A dashboard for a sales team, for example, should be checked for inherited access, drill-down exposure, export capability, and any embedded reports that bypass the intended audience. The same logic applies to flows that update records or trigger downstream actions.

This is also where periodic recertification becomes important. Builders, approvers, and business owners change over time, and a safe configuration can become risky when ownership becomes unclear or when a once-limited dashboard is copied into a broader context. Treat low-code review as an ongoing control, not a one-time launch activity.

Recertify app ownership, report subscriptions, and dashboard visibility on a fixed schedule.
Review who can create, edit, clone, and publish low-code assets.
Check whether record-level sharing, folder access, and export permissions align with intended use.
Disable or tightly govern any automation that can write data, not only read it.

Risk and Threat Considerations

Low-code platforms can magnify exposure when business users are allowed to build quickly without enough review. The main risk is not just accidental oversharing, but durable misconfiguration: a dashboard that reveals sensitive records, a workflow that exposes data through email or exports, or a connected app that expands access beyond the original trust boundary.

Failure mechanism: Security weaknesses emerge when builders inherit broad platform permissions, create assets outside formal inventory, or use data sources and sharing settings that are not reviewed for least privilege and audience scope. Attackers and insiders can then abuse overexposed dashboards, cloned apps, or mis-scoped automations to obtain data or trigger unauthorized actions.

Impact: The result can be data leakage, business-process corruption, privilege expansion, and difficult-to-detect shadow IT inside a trusted platform. If the build exposes customer, finance, or operational data, the consequence is often broader than the single app because the same pattern can be copied across many teams.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.OV — Oversight	Low-code app governance needs ongoing oversight of custom builds and ownership.
	PR.AC — Identity Management, Authentication and Access Control	Low-code access scope depends on who can build, publish, and view Salesforce assets.
	PR.DS — Data Security	Dashboards and reports can expose data beyond intended audiences.
Recommendation — Establish oversight for low-code assets, owners, and review cadence. Restrict builder and viewer access to the minimum required scope. Protect report and dashboard data with audience-aware access controls.
CIS Controls v8	6 — Access Control Management	Builder, publisher, and audience permissions must be reviewed and limited.
	16 — Application Software Security	Custom apps and automations need security review before production use.
	5 — Account Management	Ownership and accountability for low-code assets depend on controlled accounts.
Recommendation — Review and remove excessive access for low-code creators and consumers. Apply secure review gates to custom apps, dashboards, and flows. Assign accountable owners for every production low-code asset.
OWASP Non-Human Identity Top 10	NHI-01 — Inventory and Visibility	Low-code assets need a complete inventory to support governance and review.
	NHI-02 — Ownership and Accountability	Each low-code build needs a clear business owner and approver.
	NHI-03 — Least Privilege and Access Boundaries	The answer centers on restricting exposed data and actions to least privilege.
Recommendation — Maintain a complete inventory of custom apps, reports, dashboards, and automations. Tie every low-code asset to a named owner and approver. Limit each build to the smallest viable data set and action scope.

Practitioner Guidance

What to verify: Before trusting a low-code asset, verify the owner, the data sources, the audience, the sharing model, and the action path it can trigger. If you cannot explain those four elements in one review, the asset is not ready for broad use.

Implementation sequence: Start with a registry of all custom apps, dashboards, reports, and automations, then add an approval workflow for new builds, then perform recurring access and configuration reviews. If a build already exists without that evidence, treat discovery and remediation as the first task, not an afterthought.

Practitioner takeaway: The control objective is to make low-code creation observable, attributable, and bounded by business intent. If security teams only govern the platform login layer, they will miss the real risk, which is the logic and data exposure created by what users build after they get in.