Slack-controlled access
Installation starts with Slack OAuth, so the workspace owner or admin stays in control of the app relationship. Slash Social does not create a separate public signup flow that bypasses workspace approval.
Teams can remove the app from Slack when they no longer need it. Admins and operations leads can evaluate the app before they approve it for the workspace.
- Slack OAuth install
- Admin-controlled app approval
- Workspace-level removal
- No separate marketing-site account signup
Brand scope by default
Brand scope is the boundary for work, permissions, account connections, and reports. It helps agencies keep clients apart and helps in-house teams separate product lines, regions, or owned brands.
The workspace can still use shared Slack patterns, but the item, account, approval route, and report keep the brand attached. That reduces accidental cross-client context and makes support requests easier to diagnose.
- Brand-level work queues
- Brand-scoped account connections
- Role-aware approval routes
- Reports tied to the right client or brand
Human-owned publishing
AI assistance should speed up the work without hiding accountability. Slash Social can help turn intake into drafts, summarize context, classify replies, and prepare reporting notes.
Publishing remains tied to connected account state, review paths, and user permissions. That distinction belongs on the Trust page because social teams need to know who owns the final public action.
- AI-assisted drafts and summaries
- Review history before publishing
- Permission-aware actions
- Account health checks before publish
Account recovery paths
Social operations break when an account disconnects or a job fails without a visible owner. Slash Social brings those recovery paths into Slack so the team can see the issue, owner, and next action.
No platform workflow prevents every account or API issue. Slash Social focuses on making blocked work visible, owned, and actionable.
- Reconnect prompts
- Failed job visibility
- Retry paths
- Publishing blockers tied to the affected brand
Data used for the workflow
The app needs workspace, brand, role, account, content, and workflow data to plan posts, route approvals, manage recovery, triage inbox work, and build reports.
The privacy policy covers retention, deletion, subprocessors, and legal details. This page summarizes the product use in plain language for workspace reviewers.
- Workflow data used to operate the product
- Privacy policy linked from the page
- No sale of customer workspace or social media data
- Support guidance limits sensitive email content
Support with context
Support needs enough context to route a request without asking for the basics again. Workspace, brand, platform, and the short issue summary are usually enough to begin.
The contact form helps collect the right details without publishing an inbox address for scrapers. Sensitive credentials should stay out of support messages.
- Workspace name
- Affected brand
- Platform or account involved
- Short issue summary
- No passwords or access tokens