Editor permission limitation when connecting reports (PDF, XLSX, etc.)

AppSheet AppSheet Q&A
, ,
1

Hi everyone,

I’d like to ask about a limitation we’re currently facing when working with AppSheet in a team environment.

In our company, applications are owned by our Operations Manager, while the rest of the team works with Editor permissions. This setup works well for most development and configuration tasks.

However, we’ve noticed that only the app owner can configure or connect reports and files (PDF, XLSX, and other document types). Editors are unable to do this, even though they can handle most other aspects of the app.

This becomes a significant bottleneck for us, since we depend on the app owner’s availability to move forward with report-related configurations. It slows down development and makes collaboration less efficient.

My questions are:

  • Is there currently any way for an Editor to configure or connect reports/documents without being the app owner?

  • If not, is this a known limitation, and is there any plan to allow this capability for Editors in the future?

  • Are there any recommended workarounds or best practices for teams that operate with a single app owner and multiple editors?

Any insights or experiences from the community would be greatly appreciated.

Thanks in advance!

2

AppSheet connects to data, docs, etc. through the permissions of the App Owner. Because of this, AppSheet doesn’t currently allow anyone else to add sources to the app because if an editor added a source that the owner didn’t have permissions for, it would cause various errors when using that functionality within the app.

We have been working with AppSheet since 2018 and this has been a bottleneck from the beginning.

If the most important goal is to allow editors to add sources, using an account multiple people have access to own the apps will address this. The biggest issue with this that multiple people being able to access the same account is a security risk.

I wish I had better news, I would also love a better solution to this, it would make our job of building apps for clients significantly easier.

3 Likes
3

Hi @sricse
As @QREW_Ben mentioned, this has been a limitation that we have been requesting to remove.

Please take a look at the following post thread that I started in May 2025. The post thread is self explanatory.

@sricse and @QREW_Ben
May I request you to like and possibly add your supporting comments to that thread ( actually since there is not separate feature requests option where one can upvote a feature, I am requesting you to like the post, even though it sounds odd to request like to own post. :slightly_smiling_face: )

@Jose_Arteaga : Could you please update if there are any updates on this request ( the post I have attached.) As you can see this limitation keeps coming up every now and then. I was anyway about to request you for an update as 2 months have passed after the last communication.

4 Likes
4

Hi, thanks a lot for sharing this and for the detailed context.

This is exactly the same limitation we’re facing, and it definitely impacts day-to-day team development. We’ll go ahead and like the thread and add our supporting comments to help push this request forward.

Appreciate you keeping this topic active and following up on it :+1:

3 Likes
5

Thanks for the explanation, that makes a lot of sense.

It’s good to understand the technical reason behind this, even though it’s definitely been a long-standing bottleneck for team development. We agree that using a shared owner account is not an ideal solution due to security concerns.

Appreciate you taking the time to share your experience and insights :+1:

3 Likes
6

Thank you very much @sricse for adding the comment in the original post thread.

1 Like
7

Done! @Suvrutt_Gurjar Thank you for sharing!

2 Likes
8

Thank you for bringing this to my attention @Suvrutt_Gurjar,

I’ve looked into this for you, and unfortunately, there are no updates to share just yet. I have escalated the request to the Product team to evaluate its feasibility. I genuinely wish I could provide a more favorable timeline today, but I am committed to keeping this on their radar and will share any progress as soon as I have it.

3 Likes
9

Thank you @Jose_Arteaga

1 Like
10

Thank you @QREW_Ben

2 Likes
11

I would immediately consider transferring Ownership to someone on the team. I use AppSheet for 2 years. I recently made a new application, I was simply amazed by the innovations included. But don’t delay the launch of your project, better think about my idea.

1 Like
13

Hi everyone,

I’d like to highlight a collaboration challenge we’re facing while working with AppSheet in a team-based environment, and seek guidance or confirmation from the community and AppSheet team.

In our organization, all applications are owned by a single App Owner (Operations Manager), while the rest of the development team works with Editor-level access. This model works well for most app development and configuration activities.

However, we’ve observed a key limitation:

Only the App Owner is able to configure, connect, or manage reports and document outputs (such as PDF, XLSX, and other file-based reports). Editors, despite having extensive access to the app, are restricted from performing these tasks.

This creates a significant operational bottleneck. Report creation and document automation are core parts of our workflows, and progress becomes dependent on the App Owner’s availability. As a result, development speed is reduced and team collaboration becomes less efficient.

I’d appreciate clarification on the following points:

• Is there currently any supported method that allows an Editor to configure or manage reports and document connections without being the App Owner?

• If this is a known platform limitation, has AppSheet shared any roadmap or future plan to extend this capability to Editors?

• What best practices or workarounds do experienced teams follow when operating with a single App Owner and multiple Editors, especially for report-heavy applications?

This capability would greatly improve scalability and collaboration for teams working on complex or enterprise-level AppSheet solutions.

Looking forward to hearing insights from the community or AppSheet team.

Thank you in advance.

4 Likes
14

Hi @shinderavi0018 ,

We have raised a request with the AppSheet team to address the issue or limitation you have described.

You may wish to add your detailed comments ( what you have mentioned here) in that post thread and like the first post in that thread. A like is equivalent to an upvote. The link to that post is below:

1 Like
15

Hi @Suvrutt_Gurjar,
Thanks for bringing this to the AppSheet team and sharing the thread related to this. I have added my comments there and upvoted the request.
From an implementation and delivery perspective, this restriction affects team development practices. In a setup where a single App Owner controls multiple Editors, the dependency on the App Owner for report configuration and document output management is unnecessary. These are critical components of automation and are often developed upon during development and maintenance cycles.
Development speed and collaboration are impacted, especially in applications with a high report component or enterprise applications. It would be greatly beneficial to have Editors control report and document resources, either directly or through permissions.
Thanks for your efforts in consolidating this feedback and bringing about improvements on behalf of the community.
Best regards,

Manas Ghosh

2 Likes
16

You are welcome Manas.

Thank you very much for upvoting and posting your comments.

Edit: Hi @manas_ghosh

You mentioned

However I am sorry that I could not locate your addition in the post thread that I referred. If you could add the comments ( and like ) there, it would serve as a one stop reference to the issue and community’s comments on it.

1 Like