Groups documentation
Groups on Skinbase are shared creative identities for studios, collectives, release teams, and long-term collaborations. This guide explains when to use them, how to structure roles, how publishing works, and how to keep the public page clear, trustworthy, and easy to maintain.
Use a Group when a studio, crew, or release team needs its own visible brand.
Published by, uploaded by, primary author, and contributors can still reflect the real humans behind the work.
Groups work best when the team needs structure, not just a different display name.
Foundations
A Group is a shared creative identity for collaboration and publishing. It is not a replacement for personal profiles. It is the public home for work that belongs to a team, studio, collective, or release-focused collaboration.
Your personal profile is your own portfolio, reputation, and identity. It is where your individual voice, uploads, followers, and personal presence live.
A Group is the shared layer. It gives a team one public identity for publishing together, managing members, and presenting collaborative work without flattening individual credit.
Decision guide
Use a Group when the work is bigger than one person, or when a shared identity helps the team stay organized, trustworthy, and easy to understand publicly.
Decision guide
Create a Group when it solves a real workflow or identity problem. If it is just adding overhead, you probably do not need it yet.
Good fit
You collaborate with two or more people regularly.
You want a shared public brand for a studio, crew, or collective.
You publish themed drops, packs, showcases, or release-driven work.
You need shared collections, posts, assets, or release notes.
You want role-based access instead of everyone sharing one account.
Not yet
You only publish solo work and do not need a separate identity.
You are still testing ideas and not ready to manage members.
You want a Group only to rename personal work without collaboration value.
You do not want shared workflow, shared publishing context, or shared moderation responsibility.
Model
Think of a Group as two connected surfaces: a public identity page and an internal Studio workspace. One is for visibility. The other is for coordination.
The public face of the Group with branding, releases, posts, projects, challenges, events, members, and activity.
The internal workspace for permissions, publishing, review flows, releases, assets, invites, and day-to-day operations.
Groups can own artworks, collections, posts, projects, challenges, events, assets, and releases depending on the team workflow.
Not everything is public. Some areas are internal, role-based, or review-gated. The public page should be curated. Studio should stay operational.
Team structure
Keep roles understandable. Most Groups do best when only a small number of people can change settings or manage members, while everyone else gets exactly the access they need and nothing more.
| Role | Manage settings | Invite and change roles | Publish content | Review submissions | Manage posts, projects, events, releases | Manage assets and shared resources |
|---|---|---|---|---|---|---|
| Owner | Full control over branding, settings, membership policy, and archive actions. | Can invite, remove, promote, transfer ownership, and approve the overall structure. | Can publish directly and define the team workflow. | Can always review, approve, request changes, or reject. | Full access to posts, projects, challenges, events, releases, and reputation. | Full access. |
| Admin | Can usually manage day-to-day settings and operations. | Can invite and manage most members, but should not be handed out casually. | Usually yes. | Usually yes. | Usually full operational access across content areas. | Usually full access. |
| Editor | Usually limited or no access to sensitive settings. | Usually cannot change member roles unless explicitly allowed. | Often yes, depending on your workflow. | Often yes when the team uses review queues. | Good fit for content managers, release coordinators, and project leads. | Often yes. |
| Contributor | No sensitive settings access. | Cannot manage team structure. | Usually submits drafts instead of publishing directly. | Usually no. | Best for creative collaborators who need to contribute without running the Group. | Limited to what the Group makes available. |
Setup
A strong first setup prevents confusion later. Good names, clean branding, and clear role assignments make every other workflow easier.
Go to Group Studio from your main Studio area, then choose Create Group.
Pick a name people can remember and a slug that still makes sense a year from now.
Upload a recognizable avatar or logo and a cover image that gives the Group a clear visual identity.
Tell visitors what the Group makes, who it is for, and what kind of collaboration to expect.
Choose whether the Group should be public, unlisted, or private based on how ready you are.
Finish setup, then review the public page so the branding and copy feel intentional.
Bring in owners, admins, editors, or contributors based on the work each person will actually do.
Choose whether the team should use direct publishing, review-first publishing, projects, releases, or lightweight milestones.
Before the first public post or artwork, confirm that contributor credit and publishing context are correct.
Public identity
The public Group page is the identity page for the team. It should feel active, coherent, and curated instead of looking like a random collection of leftovers.
Operations
Group Studio is where you switch from being an individual creator to operating inside a shared team context. That context matters every time you publish, review, or manage content.
Use Personal Studio when you are managing your own portfolio, drafts, uploads, and audience as an individual creator.
Use Group Studio when the work belongs to the shared identity, or when roles, reviews, projects, releases, and member access need to be respected.
Publishing
Publishing as a Group means the shared identity is the public publish surface. It does not mean the Group replaces every human role in the record.
The shared identity the work appears under publicly.
The person who performed the upload or publishing action.
The person who should be understood as the main author of the work.
Additional people who made meaningful creative contributions.
Attribution
Correct attribution keeps the Group healthy. It builds trust inside the team, makes the public record clearer, and reduces avoidable disputes later.
Team health
Healthy Groups are clear about who has access, why they have it, and how that access changes as the team grows.
Invite people with the smallest role that still lets them do the work. Explain expectations before they accept so there is no ambiguity about ownership or workflow.
Review roles periodically. People change, projects end, and old permissions should not stay permanent by accident.
Quality control
Review flows help larger or more structured Groups keep public quality high without forcing every trusted team to work the same way.
The work enters the Group pipeline without immediately going public.
Editors, admins, or designated reviewers confirm quality, context, and credit.
Feedback should be specific enough that the creator knows what to do next.
Once the draft is approved, the right person can publish it under the correct Group context.
Feature ecosystem
These features are most useful when they connect. A healthy Group does not use them all at once. It chooses the smallest set that makes the public story and internal workflow clearer.
Use projects when a collaboration needs a shared home, milestones, attachments, and team ownership before it becomes a public release.
Challenges work well for themed prompts, community events, and structured contribution windows that keep the Group active.
Events are for launches, showcases, meetups, timed drops, or public moments that need a calendar-style anchor.
The asset library keeps shared files, references, and working materials organized instead of buried in chat history.
Releases package a major publication moment with summary, contributors, milestones, notes, and linked work in one polished surface.
Posts keep the Group human. Use them for updates, recruitment, changelogs, launch notes, and curated public communication.
Operating well
Most support questions come from a small set of preventable mistakes. These habits keep Groups easier to manage and easier to trust.
Avoid these
Groups become confusing when identity, permissions, and attribution drift out of sync.
Patterns
You do not need one perfect workflow. You need the right amount of structure for the team you actually have.
Owner plus one editor and one or two contributors. Simple permissions, direct publishing when the team already trusts the process.
Owner, admins, editors, and contributors with a review queue and recruitment enabled.
A team built around themed drops, packs, or showcase moments.
A Group centered on challenges, events, and recurring prompts.
FAQ
Short answers to the questions people most often ask before creating, joining, or managing a Group.
A personal profile is your individual identity. A Group is a shared identity for collaboration and publishing. The Group can publish the work publicly, but contributor credit should still show the people behind it.
Yes. Many creators keep their personal portfolio active while also publishing collaborative work under a Group. The key is to choose the right context before you publish.
Yes. Group publishing is meant to preserve authorship, not erase it. Uploaded by, primary author, and contributor credit should still reflect the humans involved.
That depends on role and workflow. Owners and admins usually can. Editors often can. Contributors may submit drafts without publishing directly if the Group uses review-first workflows.
Yes. That is one of the most useful Group workflows. Contributors can hand work off for review while editors or admins handle final approval and public publishing.
Open Group Studio, go to members or invitations, choose the right role, and send an invite only after you know what that person needs access to.
Yes. Owners and people with the right member-management permissions can update roles, revoke invitations, or remove active members when needed.
Existing publishing history and contributor credit should remain as part of the public record unless the content itself changes or is removed through normal moderation or management flows.
No. Create a Group when you need shared identity, shared workflows, or recurring collaboration. If you only publish solo work, a personal profile may be enough.
Start simple. Keep Owner count small, reserve Admin for deeply trusted operators, use Editor for day-to-day management, and keep Contributor focused on creative participation.
Yes, if recruitment is enabled. Use it when the Group is actually ready to onboard people, not just to look active.
Projects help teams organize work. Releases package major publication moments. Challenges create themed participation and energy. Together they make the Group feel structured and alive.
Yes. Posts are useful for release notes, milestone updates, recruitment, public announcements, and pinned context on the Group page.
Keep them categorized, named clearly, and cleaned up over time. Shared assets should help the team work faster, not become a second mystery archive.
Fix it quickly. Attribution errors create confusion, trust issues, and sometimes conflict. Confirm who uploaded the work, who authored it, and who contributed before changing anything publicly.
Troubleshooting
If something feels confusing, start with context, role, and visibility. Most Group issues live in one of those three buckets.
Check that you are in Group Studio, not Personal Studio. Then confirm your role allows publishing and that the Group is active and not archived or suspended.
You may not be signed in, may not belong to the Group, or may only have a pending invitation. Accept the invite first, then reload Studio.
Ask the Owner or Admin which permissions are meant for your role. In many teams, Editors manage content while Contributors only submit drafts.
Review the publish record carefully: published by, uploaded by, primary author, and contributors each mean different things. Correct the one that is inaccurate rather than replacing all of them.
Some areas may still be internal, role-limited, or pending approval. First confirm that the invitation was accepted and the membership is active.
Stop and review the affected content immediately. Confirm whether it should live under the personal profile or the Group, then correct the publish context before more linked items are built around it.
Your Group may use a review-first workflow so contributors can submit work without publishing directly. Check the review queue feedback or ask the assigned reviewer what needs to change.
Ask what they need to do this month, not what title sounds impressive. If you are unsure, start lower and promote later.
Support
Use these next steps if you are ready to create a Group, need to check your current setup, or want to contact Skinbase support.
Start with branding, visibility, and your first member invites.
Check members, workflow, releases, recruitment, and review status.
Use the general support flow if you need help untangling an account or workflow issue.
Use this if a route, permission, credit record, or workflow appears broken.
We use essential cookies to keep you logged in and protect your session. With your permission we also load advertising cookies from third-party networks. Learn more ↗
