Feature Requests

Hello! I'm a system administrator for a company with 120 employees, and I'm hoping to make a feature request. I would really appreciate it if we could have more control over custom permissions for each individual, and the ability to create permissions based on more options. Specifically, I'd like to set permissions for things like creating or copying a list, moving tasks to certain statuses, and restricting access to creating or updating labels. Basically, I want complete control over what each person can create or edit. For example, I'd like to restrict certain people from editing specific custom fields. Currently, the role system is limited, and some members have the same permissions as others, which isn't ideal. Many of my supervisors are members, but I don't want them all to have access to everything. While there are different roles we can create, the options for setting permissions are very limited. It would be great if we could have more flexibility in creating custom permissions for each individual.

There are no security permissions that can be set to control who can create a task type. We want to limit this to specific roles. We are on the custom field by task type beta and having other users able to create multiple task types can get confusing.

Through a recent support investigation, I was informed that the previous behavior, which allowed Private Custom Fields to be shared with specific Guest users, was not intended and has now been updated to function according to the intended permissions model. Under the current design, once a field is marked as Private, Guest and Limited Member access is completely blocked, and only Members can be added as exceptions. While the rationale behind the updated permissions model is understood, the previous behavior had been available for a long time and was actively used in established production workflows. A few examples: • Internal approval workflows • Employee, contractor, or supplier evaluation fields • Sensitive commercial or financial information • Client-specific operational notes However, the recent change created a significant gap for workflows that require confidential Custom Fields to be visible only to a small subset of designated users, including designated Guest users (external collaborators), while remaining hidden from anyone else. Following the permissions update, the only available alternatives are: • Making the field visible to all Guests • Promoting affected users to Members • Restructuring workflows around separate Lists and permissions models None of these options provide an equivalent level of control without introducing additional licensing costs, governance concerns, workflow fragmentation, or ongoing administrative overhead. More importantly, Workspace owners and administrators are now forced to choose between: • Exposing confidential operational data to a broader audience than intended • Removing the affected Custom Fields from their workflows • Redesigning existing workflows, SOPs, permissions structures, and operational processes around less efficient alternatives This change therefore impacts existing production environments that were already relying on this level of permissions granularity, while also removing a practical and proven access-control pattern that could otherwise be applied to future implementations. Requested enhancement: Reintroduce Guest exceptions for Private Custom Fields, enabling Workspace administrators to grant access to specific Guest users (or Teams) while keeping the field hidden from all other users. This would restore a practical and scalable permission model for confidential workflow data without requiring broader Workspace access, additional Member licenses, or workflow fragmentation.

I would like to decide whether I accept a guest from outside of my company or my workspace having the ability to export anything out of my workspace, including the views like whiteboards and things like this. I really hope very soon this will be possible.

When adding someone as an assignee or watcher to a task, if they don’t have access, instead of presenting a useless box admonishing me, how about presenting me a helpful box with a ‘share?’ Button??

It would be useful if admins could restrict limited members to view only. Currently, members can give limited members access beyond view only, which incurs a cost. We want to avoid having to monitor limited members and the access that has been given to them by members.

I’m trying to configure a Number Custom Field that should be visible to some Guests (clients) but hidden from other Guests (freelancers). Both groups must remain Guests and must have access to the same tasks. What I expected: Use Custom Field permissions and Exceptions to allow visibility for the “clients” group, while preventing visibility for the “freelancers” group. What happens: If the Custom Field is public and “Visible to Guests and Limited Members” is enabled, then all Guests can see it. There is no way to exclude one Guest group only. If I set the Custom Field to Private, the “Visible to Guests and Limited Members” toggle gets disabled (expected), but then: Guests that were previously added in the permissions/exceptions disappear after making the field Private, or When the field is Private, I cannot add Guest users to Exceptions at all (they do not appear in the “Add exception” user picker). Only members/teams seem selectable. Goal: Keep tasks shared with both client Guests and freelancer Guests. Make a specific Custom Field visible only to client Guests, and not visible to freelancer Guests. Question: Is it expected that Guests cannot be added as Exceptions for Private Custom Fields? If yes, is there any supported way to achieve per-guest-group Custom Field visibility when everyone must remain a Guest and work on the same tasks?

We have created an HR database of all employee details including contact info, pay rates, reviews, incidents, etc. that obviously needs to have permissions locked down, but we also need to publish a totally public directory with contact info for anyone to see. There is no way to use our HR Employee List and 'Add To' and directory list that will always be accurate as data is updated on the HR side without a risk of someone being able to access the data on the Directory side. We are currently using a work around of having a Directory List and having a Super Agent populate it with only the select fields we specify, but it's a ridiculous workaround to have to spend AI credits on. Instead, we should be able to control which fields get displayed on the Add To / mirrored side without a savvy user being able to view any fields from the original record. The other reason this is critical and why our Super Agent workaround is less than ideal... We need non-HR users to be able to create relationships between the Employee List and other Lists / Tasks such as Assigned Assets (vehicles, computers, etc.) The manager(s) of those assets need to be able to be able to select the Employee relationship in their appropriate Space, not HR, but the managers cannot select Employees from a relationship field unless they have access to the HR system.

We need custom permissions. I do not want to grant someone full permissions just so that they can add something to my list.

I personally would like to see the gamut of UML for developmers, but Mermaid has that and more https://mermaid-js.github.io/mermaid/#/