Access Control and Roles in ResultFly
Overview
ResultFly provides role-based access control (RBAC) so that only authorized users can create, modify, and publish campaigns. The model balances enterprise-grade governance with the flexibility marketing teams expect: every action goes through clearly defined roles, permissions, and safeguards that prevent unqualified changes to live experiences.
Organizations and Access Scope (v1)
Organizations are the top-level containers for projects and users. Access to projects is derived from organization membership:
- Users only see organizations they are members of.
- Projects are visible only inside their organization.
- Roles are assigned per organization (not per project) in v1.
Role-Based Access Control
ResultFly assigns users to roles so that access is defined by responsibilities instead of ad-hoc screen toggles.
| Role | Description |
|---|---|
| Viewer | Read-only access to campaigns, pages, and analytics for auditing or training. |
| Editor | Create and edit draft content (pages, components, assets) but cannot publish. |
| Campaign Manager | Own preview validation, manage experiments, and promote drafts to release when paired with publish permission. |
| Admin | Configure workspaces, manage membership, and delegate role assignments. |
In v1, roles are scoped to organizations, and projects inherit access from organization membership.
Action-Based Permissions
ResultFly evaluates the specific operation a user invokes. The platform supports the following representative permissions:
| Permission | Description |
|---|---|
publish_campaign | Promote a validated draft into an immutable production version. |
edit_live_campaign | Modify a live experience without creating a new version (typically restricted). |
modify_backend_apps | Change integrations, webhooks, or server-side scripts tied to the campaign. |
access_advanced_logic_nodes | Use low-code or advanced branching nodes that affect data/state. |
write_custom_code | Author or edit custom JavaScript/logic snippets inside nodes or components. |
Roles grant baseline capabilities, and these permissions fine-tune who can execute risky operations.
Controlled Access to Advanced Capabilities
Certain advanced capabilities—editing custom logic, enabling low-code scripts, connecting sensitive integrations—require explicit permission regardless of a user’s general role. Organizations can disable operations such as “write JavaScript code” for non-technical roles while leaving content editing enabled. This prevents accidental changes to mission-critical logic and keeps experimental features behind opt-in controls.
Governance and Safety by Design
The combined role + permission model enforces separation of duties by default:
- Marketing teams build and iterate safely inside preview environments.
- Technical leads retain control over integrations, backend workflows, and custom code.
- Publishing paths require the right combination of role and action permission, eliminating single-person “superuser” risk.
- Every critical operation (publish, rollback, granting access) is logged for accountability and compliance.
Scope of This Model
The access model governs what authenticated users can do inside ResultFly. It does not attempt to replace external IAM platforms, corporate SSO policies, or business rules embedded within a campaign’s own logic. Customers can integrate their existing identity providers and let ResultFly focus on in-platform authorization.
What This Enables for Teams
- Marketers can create, test, and optimize campaigns without touching protected logic or production endpoints.
- Technical specialists control advanced capabilities, custom code, and integrations, ensuring architectural integrity.
- Administrators oversee membership, assign roles, and authorize publishing, giving enterprises confidence that unqualified users cannot ship unsafe changes.