# Allow Observers to submit form or have Submiter permission **URL:** \ **Category:** Ideas & Features\ **Tags:** permissions\ **Created:** [November 14, 2025, 1:16am UTC](https://community.fibery.io/t/allow-observers-to-submit-form-or-have-submiter-permission/10001 "2025-11-14T01:16:58Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Cddd](https://avatars.discourse-cdn.com/v4/letter/c/b38774/32.png) [@Cddd](https://community.fibery.io/u/Cddd)\ **Post date:** [November 14, 2025, 1:16am UTC](https://community.fibery.io/t/allow-observers-to-submit-form-or-have-submiter-permission/10001/1 "2025-11-14T01:16:58Z")
It would be great if Observers could submit forms or add entities (submitter permission). We licensed Fibery for a subset of staff, but we also have others who only need to **authenticate** to the platform, submit forms (or add entities), and view the related views. They would not edit entities or setup views… Thanks! ---
**Author:** ![RonMakesSystems](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/ronmakessystems/32/14122_2.png) [@RonMakesSystems](https://community.fibery.io/u/RonMakesSystems)\ **Post date:** [November 14, 2025, 1:27am UTC](https://community.fibery.io/t/allow-observers-to-submit-form-or-have-submiter-permission/10001/2 "2025-11-14T01:27:55Z")
Hey! It was discussed here: [Form View - Guest Access](https://community.fibery.io/t/form-view-guest-access/3629) But it was using the old “Guest” terminology, but it’s refering to the current “Observer” ---
**Author:** ![Cddd](https://avatars.discourse-cdn.com/v4/letter/c/b38774/32.png) [@Cddd](https://community.fibery.io/u/Cddd)\ **Post date:** [November 14, 2025, 1:36am UTC](https://community.fibery.io/t/allow-observers-to-submit-form-or-have-submiter-permission/10001/3 "2025-11-14T01:36:07Z")
We are a school, and we have an app for students or parents to submit information. They can SSO and get Observer role, but giving them a paid license is not possible for us. ---
**Author:** ![AdVhPkgKad](https://avatars.discourse-cdn.com/v4/letter/a/7993a0/32.png) [@AdVhPkgKad](https://community.fibery.io/u/AdVhPkgKad)\ **Post date:** [November 14, 2025, 3:53am UTC](https://community.fibery.io/t/allow-observers-to-submit-form-or-have-submiter-permission/10001/4 "2025-11-14T03:53:00Z")
Could you (develop/have developed for you) a custom front-end and host it on your website, then use an API call to POST to Fibery? ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [November 14, 2025, 6:29am UTC](https://community.fibery.io/t/allow-observers-to-submit-form-or-have-submiter-permission/10001/5 "2025-11-14T06:29:06Z")
In this case, the data will appear to have been created by the user from whose account the API token has been taken, which I suspect is not what OP wants. ---
**Author:** ![AdVhPkgKad](https://avatars.discourse-cdn.com/v4/letter/a/7993a0/32.png) [@AdVhPkgKad](https://community.fibery.io/u/AdVhPkgKad)\ **Post date:** [November 16, 2025, 8:54pm UTC](https://community.fibery.io/t/allow-observers-to-submit-form-or-have-submiter-permission/10001/6 "2025-11-16T20:54:10Z")
sure, but if you have first / last name fields and an email, you could map them easily to a people table ---
**Author:** ![helloitse](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/helloitse/32/498_2.png) [@helloitse](https://community.fibery.io/u/helloitse)\ **Post date:** [November 17, 2025, 12:41pm UTC](https://community.fibery.io/t/allow-observers-to-submit-form-or-have-submiter-permission/10001/7 "2025-11-17T12:41:46Z")
I find this is the solution. Any process that can take in information from an infinite number of external people should not have records attributed to the users database. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [November 17, 2025, 12:56pm UTC](https://community.fibery.io/t/allow-observers-to-submit-form-or-have-submiter-permission/10001/8 "2025-11-17T12:56:12Z")
> [@helloitse](#): > > Any process that can take in information from an infinite number of external people should not have records attributed to the users database. To be fair, I think the original request is for a limited number of pre-defined users, who should be able to log in to Fibery (i.e. require authentication) to see stuff, but they should also be able to create records. Overall, the actual technical requirements are addressed with the current permissions model (i.e. Members who have Submitter access for certain dbs, but are Viewers otherwise) but I think that for some use cases, the cost of user licences for all these people is too much. Basically, the jump from viewer-only to viewer-plus-submitter is a jump from Observer to Member, and for some use cases, this feels too expensive, given that the users may not be particularly active. Unfortunately, devising a pricing plan which covers all possible use cases (and without making some people feel like they are paying too much for too little functionality) is tough. ---
**Author:** ![helloitse](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/helloitse/32/498_2.png) [@helloitse](https://community.fibery.io/u/helloitse)\ **Post date:** [November 17, 2025, 6:10pm UTC](https://community.fibery.io/t/allow-observers-to-submit-form-or-have-submiter-permission/10001/9 "2025-11-17T18:10:02Z")
Ah I see, I was thinking more about the use case than the fact that @Cddd actually has observer users already on the platform for these tickets. I agree that the current permissions & pricing model is right here. Since submitters are effectively users that create records. My approach for a team like this one, where additional user licenses is not preferred, would be to auto-link users given an email field or use an automation to read the email address value on submission and link the observer. The latter uses more of the automation quota but, it preserves an easy UX for overwriting the user value