Groups FAQ
Find quick answers about Groups without digging through the full guide.
This page answers the most common practical questions about Groups, roles, publishing, contributor credit, invites, workflows, and troubleshooting. Use it when you want fast answers first, then go deeper only if you need to.
Use the FAQ when you need answers quickly instead of reading the longer guide front to back.
Groups publish together under one identity, but the people behind the work still matter and stay visible.
This page links back to the quickstart, the full guide, Group Studio, and the creation flow.
63 questions visible
FAQ category
Basics
Start here if you need the fastest explanation of what Groups are and when they make sense.
A Group is a shared creative identity for teams, collectives, projects, and recurring collaboration. It gives multiple creators one public home for work, updates, and shared activity.
It is meant for collaboration, not as a replacement for your personal profile.
A personal profile is your individual identity, portfolio, and reputation. A Group is the team or shared identity layer.
Both can exist side by side. You can keep publishing personally while also publishing collaborative work under a Group.
Create one if you collaborate regularly, want a shared public brand, or need shared roles and publishing workflows.
If you only publish solo work and do not need a team identity yet, you can stay on your personal profile for now.
Yes. Many creators use both. Personal publishing is for individual work, while Group publishing is for collaborative work or a shared brand.
Yes, if the product allows it, but it is most useful when there is a real shared identity or collaboration reason behind it.
If it is only being used to rename personal work, a personal profile may still be the simpler choice.
FAQ category
Roles & permissions
These answers explain who can do what and why role differences exist inside a Group.
Owner is the highest-trust role. Owners control sensitive settings, membership structure, and the overall direction of the Group.
Admins usually help manage day-to-day Group operations, member access, and important content workflows.
This role should stay limited to people the Group deeply trusts.
Editors are usually the best fit for people who help manage content, publishing, reviews, releases, or coordination without needing full Group control.
Contributors participate in the creative side of the Group without needing broad access to settings or member management.
For many teams, this is the right starting role for most collaborators.
Usually Owners and Admins, depending on the Group setup. If you do not see invite controls, your role probably does not include member management.
Usually Owners and sometimes Admins. This depends on the Group’s trust model and any role restrictions already in place.
That depends on the Group role and workflow. Owners and Admins often can. Editors often can. Contributors may submit drafts without publishing directly if the team uses approvals.
Roles are not identical. One person may have a higher role or a permission override that gives access you do not have.
If you are unsure, ask an Owner or Admin what your role is meant to cover.
Usually no. Keep high-level roles limited. It is easier to add trust later than clean up a Group where too many people can change everything.
In some cases, yes. Some Groups may use permission overrides on top of the main role system.
If your team is new, it is usually better to keep the role model simple first and only customize later when there is a clear need.
FAQ category
Publishing & contributor credit
This section covers the biggest source of user confusion: how shared identity and individual attribution work together.
It means the work appears publicly under the Group identity rather than under a personal profile.
That does not erase individual authorship or responsibility for the work.
Yes. Group publishing is designed to preserve individual credit and accountability, not hide it.
Published by is the public identity the work appears under. Uploaded by is the person who handled the upload or final publish step. Primary author is the main author of the work. Contributors are additional people who made meaningful creative contributions.
The primary author should be the person who should clearly be understood as the main author of the work.
Do not choose this field based only on who clicked Publish.
Yes, if they made meaningful creative contributions. Clear credit keeps the Group trustworthy and helps avoid internal confusion later.
Yes. That is one of the main points of Group publishing: shared identity on the public surface, clear attribution for the humans behind the work.
Yes. Many creators do both. The important thing is choosing the correct context before the final publish step.
Because collaboration should not erase accountability or authorship. The Group represents the shared identity, but people still deserve clear credit for the work they did.
Fix it quickly. Review who uploaded the work, who authored it, and who contributed before making changes publicly.
If there is disagreement inside the team, resolve that first so the public record reflects a clear shared decision.
In many cases, yes, depending on your Group permissions and workflow. The best habit is to get it right before publishing so you do not have to correct it afterward.
FAQ category
Members, invites, and join requests
Use these answers when you need to manage who gets access, what role they should have, and what happens when the team changes.
Open Group Studio, go to the member or invitation controls, choose the right role, and send the invite once you know what access that person actually needs.
Yes, if your role allows member management. Owners and authorized admins can usually update access, revoke invites, or remove active members.
Their active access can be removed, but that does not usually erase the history of work they already contributed to.
Yes. Older work may still show their contribution because that is part of the record of who helped make it.
If the Group allows join requests or recruiting, yes. Otherwise access usually depends on direct invites from the team.
Recruitment mode is the public-facing signal that a Group is looking for new collaborators. It helps teams describe what roles or skills they want and how people should reach out.
Start from what they actually need to do right now. If you are unsure, start lower and promote later instead of giving broad access too early.
Yes, if your role allows it. Many teams adjust roles over time as trust, responsibility, or activity changes.
Your role probably does not include member management. That level of access is usually kept to Owners and selected Admins.
Invite controls are normally hidden if your role does not include them or if you are not operating inside the correct Group context.
FAQ category
Review workflow and approvals
These answers explain why some Groups use review queues and how that affects contributors and trusted publishers.
Your Group may use a review-first workflow so contributors can submit work without publishing directly. That helps the team catch quality, context, or credit issues before something goes public.
Usually the people whose roles include review access, such as Owners, Admins, or selected Editors.
It means the submission is not ready yet but may become ready after updates. It is a request to revise, not an automatic rejection.
Yes. That is a common Group workflow. Contributors hand work off for review while a trusted reviewer or publisher handles the final public step.
Review queues help larger or more structured teams keep public quality high, coordinate releases, and catch mistakes before launch.
No. Small, trusted teams may prefer direct publishing. Review is useful when it solves a real quality or coordination problem.
Yes, if their role allows it. Many teams reserve direct publishing for trusted operators and use review for everyone else.
Check the feedback first, then ask for clarification if needed. Treat rejection as workflow feedback, not as punishment.
FAQ category
Group features and content types
This section explains how the wider Group ecosystem fits together so users know what to start with and what to add later.
Yes. Posts are useful for release notes, updates, announcements, recruitment, or milestone communication.
Projects are for structured collaboration. They give the team a shared place to organize work, milestones, linked content, and progress.
Challenges help run themed prompts, community events, or internal creative pushes that keep the Group active and focused.
Events are for launches, streams, showcases, meetups, release windows, or any time-based public moment the Group wants to anchor clearly.
The asset library stores shared resources, references, files, and internal materials so they do not get lost in scattered chat or personal storage.
Releases package a major publication moment with a title, summary, contributors, milestones, notes, and linked work in one public surface.
No. Start with the smallest set of tools that makes your workflow clearer. Not every Group needs every feature from day one.
Most simple Groups should begin with a clear profile, member roles, artworks, and occasional posts. Add more structure only when it solves a real problem.
As the Group grows, projects, releases, review queues, recruitment, challenges, events, and shared assets become more useful.
FAQ category
Troubleshooting
Use these answers when something feels wrong, missing, or inconsistent. Most Group issues come down to context, role, or visibility.
The usual reasons are the wrong context, insufficient permissions, inactive membership, or a Group state or policy restriction. Start by confirming you are inside Group Studio and that your role allows publishing.
You may not be in the Group, may still have a pending invite, or may not be signed in. Accept the invitation first if one is waiting.
Check whether the invitation was fully accepted and whether the content you expect is internal, role-limited, or review-limited.
Your Group may be intentionally limiting that action to a higher-trust role. Ask an Owner or Admin whether your current role matches the work you are actually doing.
Review the affected content immediately. Confirm whether it should live under the personal profile or the Group, then correct it before more linked content builds around the mistake.
Check the publish record and confirm who was published under, who uploaded the work, who authored it, and who contributed. Fix the incorrect part instead of replacing everything blindly.
Member management is usually restricted to Owners and selected Admins. If you do not see those controls, your role probably does not include them.
Those areas may be internal-only, visibility-limited, or restricted by role. Confirm that you are an active member and that your role is supposed to see that content.
Approval access is usually reserved for trusted operators. If your role is Contributor or a limited Editor role, approvals may be intentionally hidden from you.
Start with the basics: complete the profile, upload branding, publish one strong piece, and add one meaningful update. A small amount of clear activity is better than a big empty shell.
Base the role on what they need to do this month, not on what title sounds impressive. If you are unsure, start lower and adjust later.