Managing marketing for multiple brands from a single platform sounds simple until you discover that most tools offer nothing more than a folder structure. One misconfiguration and Brand A's ad creative appears in Brand B's campaign. Ikon's multi-tenant architecture enforces isolation at the database row level — a structure that makes cross-brand contamination architecturally impossible, not just operationally unlikely.
In Ikon's data model, every piece of marketing data — social tokens, ad account credentials, contact lists, email sequences, content calendars, logo files, CRM records — is stored against a business_id foreign key, not against the parent account ID. This means when any automated process runs, whether it's the social scheduler, the ad optimizer, the email dispatcher, or the lead capture engine, it operates within the scope of a single Business entity. It queries only that entity's data. It writes only to that entity's records. It has no code path that could reach a sibling entity's credentials or content.
This is the correct way to build multi-tenant systems. The contrast with the competitor approach: most marketing platforms that claim to support "multi-brand management" store all tokens at the account level and use application-layer logic to route them to the right brand. Application-layer logic can be bypassed by bugs, race conditions, or misconfiguration. Row-level ownership enforcement cannot.
Each Business entity in an Ikon account is a fully independent marketing operation with its own:
business_social table keyed to this business IDEnterprise accounts have access to six permission roles, each with a carefully defined access matrix. Roles are assigned at the account level and can be further scoped to specific Business entities for territory-based access control.
| Role | Dashboard Access | Billing & API Keys | Business Management |
|---|---|---|---|
| Global Admin | All businesses, all data | Full access | Create, edit, delete |
| Account Admin | All businesses, all data | View only | Edit, no delete |
| Tech Support | All businesses, technical data | API keys only | Read only |
| Content Manager | Assigned businesses only | No access | Content only |
| Accounting | Billing dashboard only | No access | No access |
| Client (Portal) | Own business only | No access | Own settings only |
All role changes are logged to the security audit trail with timestamp, actor email, and the scope of the change — satisfying SOC 2 evidence requirements for access control reviews.
Every OAuth access token and refresh token stored in the platform is encrypted using AES-256-GCM with a per-tenant encryption key. The master encryption key is stored in an isolated key vault separate from the application database. Tokens are never logged, never transmitted in plain text between services, and are automatically refreshed before expiry using background server-side jobs. A compromised database backup would contain only ciphertext — no usable credentials.
All accounts have access to standard email/password authentication with bcrypt hashing, time-based OTP (TOTP) two-factor authentication, WebAuthn passkey authentication (Face ID, Touch ID, Windows Hello, hardware keys), and Google/LinkedIn OAuth SSO. Enterprise accounts can enforce two-factor authentication for all team members at the account level — individual users cannot disable it.
The security center tracks every active session with IP address, user agent, last-seen timestamp, and device fingerprint. Anomalous login attempts — new geography, new device, impossible travel — trigger immediate 2FA challenges and admin notifications. Accounts with excessive failed login attempts are automatically locked with configurable lockout durations. The full security log is accessible to Global Admin and Account Admin roles with 90-day retention.