Documentation

Access Beyond Roles

Most access in Qik comes from roles granted in scopes, either directly or through access passes. On top of that, a small number of built-in rules give people access because of how they're involved with a record, even when none of their roles would allow it. This article lists every one of those rules so you know exactly what someone can see and do beyond their roles.

The involvement rules work through the profiles linked to a person's login: the profiles that carry the login's email address. If a login isn't linked to any profile, none of the involvement rules apply to it. Because the link is by email address, a login can be linked to more than one profile (for example, a parent whose child's profile uses the same email address).

Access that comes from involvement

1. Assigned to a workflow card

When one of a person's profiles is an assignee on an active workflow card, they can view that card: its title, due date, current step, body, tasks, the record it's about, form requests, progress and completion status, and the people attached to it.

They can edit only the card's step, tasks and assignees. That is enough to move the card along, tick off tasks and hand it to someone else. No other field on the card can be edited through this rule.

2. People on a card they're assigned to

An assignee can also view the people attached to the card, and the person the card is about if it's about a profile. They can see only these fields:

  • first and last name
  • gender
  • email addresses
  • phone numbers

This is view-only. It does include contact details, because people working a card usually need to get in touch. Keep this in mind when you assign cards to casual staff or other people with limited access.

3. A form submission on a card they're assigned to

If a card is about a form submission, the assignee can view that submission's title, answers and linked people so they can act on it. This is view-only.

4. Rostered onto an event

Anyone with an active roster assignment for an event can view that event's title and its start and end dates. This is view-only. Assignments become inactive when the event ends, so this access ends with the event.

5. Their own roster assignments

A person can always view their own roster assignments: which event and roster, the position title and description, and the current status. They can also change the status to confirm or decline. They can't change who is assigned, which roster or which event.

This covers every profile linked to their login, so a parent can answer an assignment for a child whose profile uses the parent's email address.

In roster views a person always sees their own row. Anyone who can view a roster sees every row on it.

6. Holding a position in a group

If someone holds a position in a group, and that position either grants roles or lets them leave the group, they can view the group's name. Nothing more comes from this rule. What they can do inside the group comes from the roles on the position. See Scopes and Groups.

7. Editing their own profile (self-service)

This rule is opt-in. If a person holds a role with Self service editing turned on, they can edit:

  • the profiles linked to their login
  • their under-18 dependants (child, grandchild, niece or nephew relationships)
  • their spouse

They can edit only the fields you've ticked for self-service in that role. There's no "all fields" option; each field has to be ticked. See Self-service profile editing.

8. Conversations they're in

If a person's own profile (the main profile for their login) is a participant in a conversation, and messaging is turned on for your organisation, they can do the following without any role:

  • view the conversation and every message on it
  • reply with an ordinary message, unless the conversation has been set up so that participants can't reply
  • edit the text of their own messages, and delete their own messages
  • leave the conversation

They can't rename, archive or delete the conversation, change who's in it, or edit anyone else's messages. Posting or editing a message that uses a custom message form still needs a role for that form. Being in a conversation also gives no access to the records, files or people that its messages mention or link to. Those keep their own permissions. Other profiles that share the login's email address (such as a child's) don't count as the person for this rule.

Access that applies to records themselves

9. Public records

Anyone can read a record whose security is set to Public, including visitors who aren't signed in. Public only covers reading. Editing a public record still needs the right permissions.

10. Media linked from an email or text message

Links in an email, email campaign or SMS can open the files, images, videos and audio that the message references, without the recipient signing in. The link works only for media attached to or referenced by that message, never for other kinds of records.

Access that comes from who the user is

11. Administrators

An administrator can view and edit everything in their own organisation. Being an administrator in one organisation gives nothing in another.

12. Knowing which content types exist

Anyone who has a permission on a custom content type (a particular form, workflow or other definition) can see the basic information about content types that they need to make sense of it, even without a permission on content types themselves.

Things that look like exceptions but aren't

These still need a role that grants them, in a scope that contains the record. See How permissions are named for the details.

  • Ownership: "own" permissions (for example Edit own) cover records the person created, records they've been made an owner of, and records where one of their profiles is listed as an assignee.
  • Participation: "if participant" permissions (for example List if participant) cover conversations that list one of the person's profiles as a participant, plus the messages on them.
  • Stronger permissions include weaker ones: for example, edit includes view, view includes list, and "any" includes "own".

Summary

None of the involvement rules (1–8) allow editing unless they say so. These are the only edits they allow:

  • moving a card you're assigned to (step, tasks, assignees)
  • confirming or declining your own roster assignment
  • self-service profile edits, limited to the fields you've allowed
  • replying in a conversation you're in, and editing or deleting your own messages

Everything else is view-only, and only for the specific records the person is involved with. To check what a particular person can reach, use impersonation to see the dashboard as they see it.

FAQs

Why can a casual staff member see someone's phone number when their role doesn't allow it?
Does being rostered onto an event let someone edit the event?
Can people in a conversation open the files and records shared in it?
Does making a record Public let anyone edit it?