Custom-widget data and permissions

A package says what kind of data it understands. Your installed widget says which of your data it may use. Those are deliberately separate: installing someone else's spending widget never gives it a bank or feed until you choose one and approve the resulting access.

Bind logical inputs#

Open the widget inspector's Data tab. Each package input has its own card—such as Transactions, Budget, or Loans—and a status: Bound, Choose data, or Needs mapping.

1. Choose a compatible synced feed or live bank source for each required input.
2. BankSync asks the server for that concrete source's available schema and proposes compatible fields.
3. Review the compiled mapping summary. Only those projected fields are delivered to the sandbox.
4. Configure package settings. Appearance/placement settings live in the Style tab.

If an automatic mapping is incomplete, use the field selectors in the same input card to repair it. For live banks, choose one account or all accounts. Transaction and trade inputs can also set an absolute date window; leaving both dates blank uses the provider default.

A widget with two inputs receives two independent datasets. A refresh or error in one does not clear the other. The package sees logical names such as transactions and projected widget-local field names. It does not receive your feed ID, bank ID, credentials, or access token as row data or SDK configuration.

Bank versus synced feed#

Both can satisfy the same logical resource contract. Choose a live bank for provider-current data or a synced feed when you want the destination-backed snapshot and its configured mappings. When an API binding includes account/date restrictions, the server applies them before summaries are calculated, so a total cannot include rows outside the approved window and merely hide them afterward.

Permission review#

Custom code starts paused. On the dashboard, a workspace administrator reviews:

• the exact immutable package version;
• every bound input and projected field set;
• requested capabilities;
• any external network host;
• optional account and date narrowing.

BankSync builds this review from the current server-owned package and binding. Feed, bank, and account names are resolved for people; opaque source IDs are not used as the primary permission language. If the package, binding, or widget version changed while the dialog was open, approval is refused and the review must be loaded again.

Approval is bound to the package digest and binding fingerprint. The widget version prevents stale approval and update requests but is not permission identity. The current viewer's permissions can only narrow that authority. The sandbox never receives a sign-in credential.

Changing ordinary display settings does not require review. Rebuilding code, upgrading the package, rebinding an input, changing a projected mapping, or requesting a new capability does.

Revoke and repair#

An administrator can revoke a grant at any time; the next render is denied immediately, even if a short-lived token was minted seconds earlier. The widget stays installed but receives no workspace rows.

If an input becomes incompatible after a source schema changes, the inspector marks it Needs mapping and exposes compatible concrete columns. Repair the map or choose another source. BankSync does not silently guess across a required-field mismatch or fall back to a different source.

If a live bank's provider consent expires, the input is paused and the inspector asks you to reconnect that bank. A general source failure remains distinct from schema drift: reconnect or repair the source first, then rerun binding preview. On a locked dashboard the same binding, mapping, settings, and permission state remains visible, but configuration controls are read-only. Revoking a grant remains available to an administrator as a security action independent of layout locking.

Error states#