Alternative to granting 'snc_patform_rest_api' role to user when using OOB sn-record-picker directive as a reference field

[cynlink1]

We are currently working with a partner to configure a store app to work in our instance. The scoped app's portal uses the OOTB sn-record-picker directive as a reference field for custom forms. This directive uses the TABLE API to retrieve the information and display the values to the user, in general the Table API uses the ACL's for authorization. My organization has limited the Table API "Execute" ACL to the snc_platform_rest_api_access role. In additional to activating the OOTB ACL, a previous developer created a custom Table API 'Execute' ACL to allow integration account(s) access to execute on specific tables. Basically, we have set up least privileged access to the tables used by each integration user. The solution the previous developer created is specific to 'integration' users and isn't one that we want to implement for users (customers) or groups of users (customers). 

The partner wants us to add the snc_platform_rest_api_access role, which is associated to the Table API 'Execute' ACL to multiple end-users (customers) so the OOTB sn-record-picker directive reference fields will work as expected. They state that right now even if the table level acl's are met, the users still require the snc_platform_rest_api_access role to execute the Table API's. This is currently impacting the snRecordPicker directive that is using table api's to retrieve data. Is there a workaround for this scenario that does not involve granting the snc_platform_rest_api_access role to the users? If the role MUST be assigned to the users, how do I limit those user's API access to ONLY the tables in the scoped app?

If it isn't obvious, I do not have much experience in this area. Any guidance would be appreciated.  

Thanks,

Cyn

[John Dewhurst]

Thanks for the response, that last comment was my argument against the need for the api level restriction, good to have that seconded.