PROJECTS & TASKS
Project access overview
Understand project membership, visibility, roles, and project-scoped permissions.
Understand project membership, visibility, roles, and project-scoped permissions. This guide is written for project leads and contributors and explains both the recommended workflow and the checks to make when the result is not what you expect.
Before you begin
- Sign in to RIIW with the account you intend to use for this work.
- Confirm the active organization in the organization switcher. RIIW keeps each organization’s members, settings, and work separate.
- Make sure your role includes the capability required for the action. If a control is missing rather than disabled, access is the most likely reason.
- Save any unsent text before changing browser, organization, or project context.
Tip: Use the narrowest access that lets a teammate complete their work. Clear ownership and intentional permissions make later troubleshooting much easier.
Project access is separate from organization access
Every project belongs to an organization, but each project has its own access configuration. Open a project and choose Settings to manage the two relevant areas:
- Access contains Project Access Roles and non-member project visibility.
- Project Members contains the project roster and the role assigned to each member.
New projects default to project-members-only access. An authorized project administrator can change non-member visibility to All organization members, which lets organization members view the project and related organization activity. It does not turn those viewers into project members or grant broad editing permissions.
Project roles are the source of truth for project settings, membership, workflow, custom fields, tasks, attachments, sprints, tags, exports, and reports. Organization membership is still required before a person can be added to a project.
Project access overview: step by step
- Open RIIW and go to the target organization, then Projects or the project’s Settings page.
- For project access overview, first confirm project type, project membership, project role, visibility, task owner, status, priority, and dates. This prevents a valid action from being applied in the wrong scope.
- Follow the control named in the page heading or action menu. Understand project membership, visibility, roles, and project-scoped permissions. If the control is not visible, stop and check access instead of choosing a similar action elsewhere.
- Enter the required values and add enough context for a teammate to understand the change. Keep names concise; put rationale and acceptance details in description fields.
- Review visibility, ownership, dates, and linked items before saving. RIIW validates required fields and permission boundaries during this step.
- Submit once and wait for the success state. A button can remain busy while RIIW validates access, storage, or a concurrent update.
- Confirm that the project, member, role, or task reflects the saved value without changing another project’s access.
Recommended practices
Keep context explicit
Use descriptions and comments to capture the reason for a decision, not only the result. Link related project work or supporting documents when a future reader would otherwise need to search for them.
Choose a consistent owner
Assign one accountable owner whenever the workflow supports ownership. Other contributors can still collaborate, but a single owner reduces ambiguity and makes notifications actionable.
Review access after structural changes
Changing organization membership, project membership, project visibility, or a role can alter who is able to see or update an item. Verify access in the affected scope instead of assuming organization and project permissions are interchangeable.
What different people can do
| Person | Typical access |
|---|---|
| Organization owner or admin | Configure organization-level behavior and manage members when their role permits it. |
| Project owner or project administrator | Manage the project when their project role grants the required permission. |
| Organization member | Use enabled organization modules and shared areas allowed by their organization role. |
| Project member | View and contribute inside a project according to that project’s assigned role. |
| Platform support | Investigate an authenticated support ticket; it does not silently join your organization. |
Exact controls depend on organization membership, the organization role, enabled modules, project visibility, project membership, and the assigned project role.
Troubleshooting
The control is missing or disabled
Confirm that you are in the expected organization and that the relevant module is enabled. For an organization-wide control, ask an organization owner to review your organization role. For a project control, check that project’s membership and project role. Signing out and back in can refresh access after a recent role change.
The page shows old information
Refresh the page once. If the issue continues, close duplicate RIIW tabs, sign in again, and retry in a current browser. Avoid clearing site data until you have copied any unsaved text.
The action fails after you submit it
Read the inline error first; RIIW commonly identifies a missing field, access rule, limit, or conflicting update. Check your network connection and retry once. Repeated submits can create confusing duplicate work in workflows that are not naturally idempotent.
Get more help
Search this Help Center for the exact control or error message. For a product problem, open an authenticated RIIW support ticket and include the affected organization, module, expected result, actual result, and reproduction steps. Add a screenshot or short video only when it does not expose passwords, tokens, payment details, or unrelated personal data.