LinkedIn
Twitter
Problem:
AppSheet's "Application Access Keys" currently offer only full permissions. This lacks granular control, preventing users from defining specific CRUD operations (e.g., allowing Adds and Updates but not Deletes) for different third-party services or end-users. This forces over-privileging API keys or complex external validation.
Proposed Solution:
Implement granular permissions for AppSheet's Application Access Keys. Add toggle options with distinct checkboxes for each operation:
Updates: (Checkbox) Allows modification of existing records.
Adds: (Checkbox) Allows creation of new records.
Deletes: (Checkbox) Allows deletion of existing records.
Read-Only: (Toggle/Checkbox) If enabled, allows only read operations and disables other CRUD checkboxes.
Benefits:
Enhanced Security: Enforces the principle of least privilege, reducing attack surface.
Improved Control: Finer control over external system interactions, ensuring data integrity.
Wider Integration Capabilities: Enables more sophisticated integrations without custom backend logic.
Simplified Development: Reduces need for external permission management.
Compliance: Helps meet regulatory requirements for data access control.
Use Cases:
Reporting Tools: Strictly "Read-Only" API keys (e.g., for Looker Studio).
Data Ingestion Service: "Adds" and "Updates" only
User Profile Management: "Read" and "Update" for external user portals.
Public Forms: "Adds" only for form submissions.
Granular API key permissions will significantly enhance AppSheet's integration capabilities, offering greater security, flexibility, and control.
