> For the complete documentation index, see [llms.txt](https://docs.in8sync.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.in8sync.com/client-admin-guide/getting-started/entity-components.md). # Entity Components Find, view, create, and manage entity records — customers, vendors, partners, and contacts — directly inside the portal. Entity components are how a workflow finds, displays, and creates the people and organisations behind every transaction — customers, vendors, partners, and contacts. The classic pattern is **search → select → display**: an Entity Search drives an Entity 360 (or downstream blocks like Address) once the user picks a result. For Order Form contexts, **Customer/Vendor Selection** plays the same role and integrates with Order Lines. {% hint style="info" %} **How these fit together:** see [Common Patterns](/client-admin-guide/getting-started/common-patterns.md) for the recommended entity search page layout, and [Transaction Components](/client-admin-guide/getting-started/transaction-components.md) for how Customer/Vendor Selection drives an order form. {% endhint %} ## Components in this category
Customer/Vendor SelectionEntity picker for Order Form pages — drives Address, Order Lines, Customer Field.#customer-vendor-selection
Entity SearchLookup interface for customers, vendors, or partners with configurable result columns.#entity-search
Entity 360 ViewFull tabbed profile — metrics, financial, addresses, contacts, attachments, orders, deposits.#entity-360-view
Create EntityConfigurable form for creating new entities — inline or modal.#create-entity
AddressDisplay billing/shipping address from the selected customer, with order-type filtering.#address
Select Customer AddressLets the user pick from the customer's saved addresses.#select-customer-address
Customer Hold StatusSurfaces credit holds and supports PIN-based manager override.#customer-hold-status
PIN PadNumeric PIN entry for module-wide gates and standalone PIN-required pages.#pin-pad
Support Case ManagerSupport-case manager block — list customer cases, see status and priority, create new cases.#support-case-manager
## When you'd reach for this category * **Order Form context** → Customer/Vendor Selection (entity picker that integrates with the order). * **Lookup-only pages** → Entity Search + Entity 360. * **New entity from a workflow** → Create Entity (inline or modal). * **Order shipping/billing addresses** → Address + Select Customer Address. * **Credit hold gating** → Customer Hold Status (with PIN override). * **Customer-facing support cases** → Support Case Manager (list and submit on the customer's record). * **Module-wide PIN gates** → PIN Pad. *** ## Customer/Vendor Selection The entity picker for Order Form pages. Lets the cashier or sales rep search a customer (or vendor) by name, email, or phone, and select one. Once picked, the entity is published to the page's session state — Address, Customer Field, Order Lines, and other blocks read from there automatically. The block also handles a few common shortcuts: auto-set the logged-in user as the entity, or auto-set the location's default customer. > **Note on naming:** The palette label is **Customer/Vendor Selection**. Some older docs and the underlying file call it *Customer Select*. ### Available in * Order Form modules **only** ### When to use * Any Order Form page where the order is associated with a customer or vendor (which is most of them). * Place it at the **top of the page** so downstream blocks have an entity to read from. * For Vendor-driven order flows (e.g. drop-ship, purchase orders), set Entity Type to *Vendor*. For lookup-only flows (no order being created), use **Entity Search** instead. ### Settings | Setting | Description | | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | **Title** | Heading text shown above the picker. Default: *Customer/Vendor*. | | **Default Entity ID (optional)** | Pre-select a specific entity by ID when the page loads. | | **Auto-set Entity for Logged In User** | If the signed-in user is themselves a Customer or Vendor entity, auto-select them. Default: No. | | **Use Location Default Customer** | Auto-select the location's configured default customer (useful for retail POS where every walk-in defaults to a *Cash Sale Customer*). Default: No. | | **Entity Type** | What this picker searches for: Customer or Vendor. Default: Customer. | ### How it works 1. The user types a name, email, or phone fragment. 2. Matches are fetched live from NetSuite via the entity search. 3. The user picks an entry from the results. 4. The picked entity is written to the page's session state — `selectedCustomer` / `customerDetails`. 5. Downstream blocks (Address, Customer Field, Order Lines, Customer Hold Status) read from that state and re-render. If the user clears the selection manually, the auto-set rules don't re-apply — preventing the picker from "fighting" the user. {% hint style="info" %} Click the **Eye icon** next to a selected entity to open a modal showing their full contact info and addresses — useful for quick verification without leaving the page. {% endhint %} ### Examples **Cashier register.** Customer/Vendor Selection at top with *Use Location Default Customer* enabled. Walk-in sales auto-default to the *Cash Sale Customer*; named transactions override by typing a customer name. **B2B portal.** Customer/Vendor Selection with *Auto-set Entity for Logged In User* enabled. The logged-in customer's account is selected automatically — no search needed. **Vendor PO entry.** Customer/Vendor Selection with Entity Type set to *Vendor*. Used at the top of a Drop Ship workflow. ### Related (Component) * [#entity-search](#entity-search) — The lookup-only alternative for non-Order-Form contexts. * [#address](#address) — Reads the selected customer to populate billing/shipping addresses. * [#customer-hold-status](#customer-hold-status) — Reads the selected customer's hold status and warns the cashier. *** ## Entity Search A lookup interface for entity records. Configure which entity type it searches (Customer, Vendor, or Partner), which fields users can search against, and which fields appear in the results table. The block's display label updates based on the entity type — *Customer Search*, *Vendor Search*, or *Partner Search*. ### Available in * All module types ### When to use * Lookup pages where users find an entity to inspect (pair with Entity 360 in the same page or a Modal). * Customer service workflows. * Anywhere you'd previously have built a "Find a customer" page. For Order Form contexts where the entity is the basis for a transaction, use **Customer/Vendor Selection** instead — it integrates with Order Lines, Address, and the rest of the order flow. ### Settings | Setting | Description | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | **Title** | Heading text shown above the search. | | **Entity Type** | What this search looks up: Customer, Vendor, or Partner. Default: Customer. | | **Show Quick Actions** | Show the per-result quick-action buttons (e.g. View, Edit). Default: Yes. | | **Hotkey** | Optional keyboard shortcut to focus the search input (e.g. *ctrl+c*, *alt+c*). | | **Hidden** | Hide the block from the front end (useful when only the underlying selected-entity state is needed by other blocks). Default: No. | | **Advanced Configuration** | Opens the configuration modal — searchable fields, display fields, contact search, default entity, location handling, table view, custom filters. | The Advanced Configuration modal supports: * **Multi-Search Character Exclusions** — strip specified characters from the search query before sending it (useful when scanners or IDs include separator characters like colons or slashes). * **Search Contacts** — include contact records in the search (for Customer entity type). Default: on. * **Search All Subsidiaries** — search every subsidiary rather than just the current one. Default: off. * **Use Location Default Customer** — auto-load the location's default customer when the page opens. * **Use Table View** — render the entity list modal as a proper HTML table (recommended for accessibility). Default: on. * **Default Entity** — pre-load a specific entity by ID. * **Use Dynamic Default Entity** + **Dynamic Default Entity Value** — pull the default entity from page or session state (e.g. *user.id*, *selectedCustomer.id*) instead of a fixed ID. * **Searchable Fields** — toggle which fields the search query checks (entity ID, email, phone, etc.). * **Hidden Columns** — searchable fields hidden by default in the entity list modal (the user can still toggle them on). * **Display Fields** — which fields appear in the selected-entity card. * **Advanced Entity Filter** — a custom filter condition that further narrows the entity search. Used by administrators when they need filtering beyond the standard searchable fields. * **Advanced Contact Filter** — same, for the contact search. ### How it works 1. The user types a search term. 2. Matching entities (and optionally contacts) are fetched and shown in the results table. 3. The user clicks a result to select it. 4. The selected entity is published to session state — Entity 360 (or any reader) picks it up and shows details. 5. A `entity-afterSelect` JavaScript hook fires when an entity is selected. Container width drives responsive sizing — the search adapts at narrow widths to keep the input and results readable. {% hint style="info" %} Pair Entity Search with **Entity 360** in the same page (or in a Modal triggered from each row's quick action) for the classic find-then-inspect pattern. {% endhint %} ### Examples **Customer service lookup page.** Page module with Entity Search at the top (Entity Type = Customer, Search Contacts on) and Entity 360 below it. Agent types a name, picks a result, sees the full profile. **Vendor directory.** Page module with Entity Search (Entity Type = Vendor) — the team uses it to find vendor contact info. **Partner program admin.** Entity Search with Entity Type = Partner, used to manage partner accounts. ### Related (Component) * [#entity-360-view](#entity-360-view) — The detail view that pairs naturally with Entity Search. * [#customer-vendor-selection](#customer-vendor-selection) — The Order Form alternative that drives a transaction. * [#create-entity](#create-entity) — For creating new entities when search returns no match. *** ## Entity 360 View A comprehensive detail view of one entity (Customer, Vendor, or Partner). Renders as a tabbed interface — Profile, Financial, Addresses, Contacts, Attachments, Orders, Deposits — with each section toggleable on or off depending on what's relevant. For Vendors, only the Profile and Addresses tabs are shown — Financial, Contacts, Attachments, Orders, and Deposits are hidden automatically. ![Entity 360 View with multiple tabs across the top — Profile selected, showing key metrics, contact info, and financial summary cards](https://229581143-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAG04Mxmhw6PLRAZBvhtK%2Fuploads%2Fgit-blob-6b4abb20cd507081f74b71548a6e5b8cdeceec04%2Fpb-entity-360.png?alt=media) ### Available in * All module types ### When to use * Customer service pages where agents need a single-screen view of an account. * Account management dashboards. * Inside a **Modal** triggered from an Entity Search result row. * Anywhere you need rich entity detail beyond a few fields. For light-weight entity info (e.g. just the phone number on an order page), use **Customer Field** instead. ### Settings | Setting | Description | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | **Title** | Heading text shown above the view. Default: *Entity 360*. | | **Default Customer ID (optional)** | Pre-load a specific entity by ID. Otherwise the view reads the selected entity from session state. | | **Show Key Metrics** | Display the metric cards (balance, orders, deposits) at the top. Default: Yes. | | **Show Contact Information** | Display the contact info section. Default: Yes. | | **Show Financial Information** | Display balance, credit limit, unbilled, overdue, payment terms. Default: Yes. | | **Show Address Management** | Display the addresses tab with CRUD. Default: Yes. | | **Show Contact Management** | Display the contacts tab with CRUD. Default: Yes. | | **Show Order History** | Display past orders for the entity. Default: Yes. | | **Show Deposit History** | Display past deposits. Default: Yes. | | **Compact View** | Collapse to icon-only tabs and condensed content. Default: No. | | **Advanced Configuration** | Opens the configuration modal — per-tab fine-tuning, default tab, custom field display, sort and pagination, action buttons, attachment policies. | The Advanced Configuration modal lets you tune each part of the view in detail: * **Display** — default tab on open, search across all subsidiaries, show/hide New Entity / Edit / Refresh buttons, override field labels (Company Name, First Name, Last Name, Email, Phone, Address), add custom status bubbles mapped to any entity field, add and configure custom metric cards mapped to fields such as Total Revenue, Balance, or Credit Limit. * **Profile tab** — toggle Show Custom Fields; and a Custom Fields manager to add/remove/reorder specific NetSuite fields, set a display label, and choose a display type (text, email link, phone link, URL link, or image) for each. * **Financial tab** — granular toggles for Balance, Credit Limit, Unbilled Orders, Overdue Balance, Days Overdue, and Payment Terms. * **Addresses tab** — which columns to show in the address table. * **Contacts tab** — enable/disable creating contacts, enable/disable editing contacts, and contact form field configuration (mark phone, title, role, and notes as required or hidden). * **Attachments tab** — the tab label. * **Orders tab** — display type (cards or table), page size, and custom row action buttons. ### How it works 1. The block reads the selected entity from session state (or uses the configured Default Customer ID). 2. Tabs render based on the toggle settings. 3. Each tab fetches its own data on first view (lazy load). 4. Sub-views in Addresses, Contacts, Attachments, Orders, and Deposits include CRUD modals for create/edit. 5. A Refresh button re-fetches the entity and clears cached tab data. The Financial tab summarises balance, credit limit, unbilled orders, overdue balance, and payment terms (including amounts in the entity's configured currency for multi-currency accounts) — useful for AR and account-management workflows. {% hint style="info" %} Use **Compact View** when you've placed Entity 360 inside a smaller container (sidebar, modal, dashboard tile). Compact mode shows tabs as icons only and condenses metric cards. {% endhint %} ### Examples **Customer detail page.** Entity Search at top, Entity 360 below. Agent picks a customer; the full 360 view loads with all tabs enabled. **Vendor profile.** Default Customer ID set to a vendor's NetSuite ID. Show Financial / Contacts / Orders / Deposits all off (Vendor doesn't use them anyway). **Account-management dashboard tile.** Entity 360 in Compact View, placed in a Column. Quick at-a-glance balance plus the option to dive into Orders. ### Related (Component) * [#entity-search](#entity-search) — The lookup block that drives Entity 360. * [#customer-hold-status](#customer-hold-status) — Surface AR holds in context with the entity profile. * [Transaction Components — Customer Field](/client-admin-guide/getting-started/transaction-components.md#customer-field) — For lightweight single-field display instead of full profile. *** ## Create Entity A form for creating a new entity record without leaving the portal. The whole form is configured through one modal — pick which fields appear, mark which are required, set widths, decide between inline and modal presentation, and define what happens on save. ### Available in * Page modules * Order Form modules * Catalog modules ### When to use * Order Form pages where the cashier may need to create a customer on the fly (rare new-walk-in scenario in retail). * Customer service pages where agents create customers as part of handling a new account. * B2B portals where a sales rep onboards a new business contact. * Anywhere "create new" sits naturally next to "search existing". ### Settings | Setting | Description | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | **Configuration** | Opens the configuration modal — the only setting on the block surface. All field, layout, and behaviour options live in the modal. | The configuration modal supports: * **Display mode** — Inline (form embedded on the page) or Modal (button opens a pop-up form). * **Main fields** — toggle each main entity field (visibility, required). * **Address fields** — toggle each address field on the form. * **Custom fields** — add custom NetSuite fields with order, width, and field type. * **Contact create / edit** — allow contact records to be added during entity creation. * **Per-field controls** — required, hidden, width, label override. ### How it works 1. Form renders according to the configured fields and visibility. 2. The user fills in required fields. 3. On save, a NetSuite entity record is created via the SuiteCloud RPC. 4. The new entity is published to session state — downstream blocks can read it immediately. 5. Optional contact creation runs alongside, attaching contacts to the new entity. In edit mode the block shows a placeholder summary indicating how many fields are configured. {% hint style="info" %} Use **Modal** display mode for Order Form contexts where Create Entity isn't the primary action — it stays out of the way until needed. Use **Inline** for dedicated "create new customer" workflows where the form is the page. {% endhint %} ### Examples **On-the-fly customer creation in POS.** Entity Search at top, Customer/Vendor Selection below it, Create Entity in Modal mode triggered by an Action Button labelled *New Customer*. **Dedicated onboarding workflow.** Page module dedicated to new-customer onboarding. Create Entity in Inline mode with all main + address + a few custom fields enabled. **B2B partner onboarding.** Create Entity configured for Partner entity type, with custom fields for partner program code and tier. ### Related (Component) * [#entity-search](#entity-search) — Pair with Entity Search so users find existing entities before creating new ones. * [#customer-vendor-selection](#customer-vendor-selection) — The Order Form picker — pair with Create Entity for create-then-use flows. *** ## Address Displays the current order's billing and shipping addresses, lets the user pick from the customer's saved addresses, and supports creating a new address inline. Pairs with **Customer/Vendor Selection** (which sets the customer) and **Select Customer Address** (which provides the picker). ### Available in * Order Form modules **only** ### When to use * Standard placement on every Order Form page that ships physical goods or invoices to a billing address. * Order types where the address differs from the customer's default (e.g. drop-ship, delivery). * For pickup-only orders with no shipping, you can configure Order Types so the block hides automatically. ### Settings | Setting | Description | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Title** | Heading text shown above. Default: *Address*. | | **Address Type** | Which address(es) to show: Billing, Shipping, or Both. Default: Billing. | | **Order Types** | Multi-select filter — block only shows for the selected order types. Options: Cash & Carry, Drop Ship, Delivery, Pickup, Special Order, Quote. Empty list = always show. | | **Use Location Address** | When on, the block uses the order's active location address as the default for the configured order types, rather than the customer's saved address. Useful for workflows where the ship-from or bill-to is the store/warehouse location. | | **Debug mode** | Surface diagnostic info for troubleshooting address issues. Off / On. Default: Off. | ### How it works 1. Reads the selected customer from session state (set by Customer/Vendor Selection). 2. Loads the customer's address book. 3. Displays the configured Address Type with default-address pre-selected. 4. The user can switch the displayed address (via Select Customer Address) or create a new one inline (via the New Address dialog). 5. The chosen address is written to session state and used at order submit. If **Order Types** is configured, the block checks the current order type and hides itself when not in the list. A request-ID mechanism prevents stale fetches from overwriting newer data when the user changes customer or order type rapidly. {% hint style="info" %} For separate **Bill To** and **Ship To**, use two Address blocks — one with Address Type = Billing and one with Shipping. Or use a single block with Address Type = Both for a stacked display. {% endhint %} ### Examples **Standard delivery flow.** Customer/Vendor Selection at top → Select Customer Address (Shipping) → Address (Address Type: Both, Order Types empty). Customer's default ship/bill addresses load; user can change. **Pickup-only order.** Address with Order Types = `[Cash & Carry, Pickup]`. The block hides for Delivery and Drop Ship orders. **Drop-ship workflow.** Address with Order Types = `[Drop Ship]` only. Address only appears when the order type is Drop Ship. ### Related (Component) * [#select-customer-address](#select-customer-address) — The picker that drives which address Address displays. * [#customer-vendor-selection](#customer-vendor-selection) — Sets the customer whose addresses are read. * [Transaction Components — Shipping Method](/client-admin-guide/getting-started/transaction-components.md#shipping-method) — The shipping-method picker that pairs with the shipping address. *** ## Select Customer Address A dropdown that shows all of the currently-selected customer's saved addresses, filtered to billing or shipping. The user picks one, and the chosen address becomes the active billing/shipping address for the order. ### Available in * Page modules * Order Form modules * Catalog modules ### When to use * On Order Form pages where the shipping or billing address may differ from the customer's default address. * When the customer has multiple addresses on file and the user needs to pick a specific one. * For checkout flows that distinguish between *Ship To* and *Bill To*. If you only ever want to display the customer's default address, use **Address** alone — Select Customer Address is for picking when there are multiple to choose from. ### Settings | Setting | Description | | ----------------------------- | ------------------------------------------------------------------------------- | | **Title** | Heading text shown above the picker. Default: *Customer Address*. | | **Address Type** | Which address kind this picker manages: Billing or Shipping. Default: Billing. | | **Show Preview in Edit Mode** | Show a sample preview while editing the page in the Page Builder. Default: Yes. | ### How it works 1. Reads the selected customer (from the page's session state, set by Customer/Vendor Selection). 2. Fetches the customer's address list from NetSuite. 3. Auto-selects the customer's default address (matching the configured Address Type). 4. The user can change the selection from the dropdown. 5. The chosen address is written back to session state and read by downstream **Address** blocks. The block hides itself if the signed-in user isn't a customer entity, or if the customer has no addresses on file (in non-edit mode). {% hint style="info" %} JavaScript hooks are available for advanced flows: `selectCustomerAddress-afterAddressesFetch` (modify the address list before display), `selectCustomerAddress-beforeAddressSelect` (validate a pick), `selectCustomerAddress-afterAddressSelect` (run side effects after pick). See the [JavaScript](/client-admin-guide/getting-started/advanced-components.md#javascript) component. {% endhint %} ### Examples **Order with separate billing and shipping.** Two Select Customer Address blocks: one with Address Type = Billing, one with Address Type = Shipping. Two corresponding Address blocks below display the selected addresses. **Pickup vs delivery flow.** A Select Customer Address with Address Type = Shipping, only enabled when the order type is *Delivery* — paired with the Address block's order-type filter. ### Related (Component) * [#address](#address) — Displays the selected address — pair both blocks together. * [#customer-vendor-selection](#customer-vendor-selection) — The upstream block that selects the customer this picker reads from. *** ## Customer Hold Status Shows whether the currently selected customer is on hold and (optionally) lets a manager override the hold via PIN. When the hold is active and unoverridden, the order's Submit Button is blocked from completing. The hold check can be a fixed field on the customer record, an automatic credit-formula evaluation (e.g. balance > credit limit), or always-on / always-off for testing. ### Available in * Order Form modules * Page modules * Catalog modules ### When to use * Order Form pages where you need to enforce credit holds before allowing a transaction. * Customer detail pages where AR holds should be visible at-a-glance. * POS workflows where the cashier needs a clear visual cue plus the ability to escalate to a manager. For visibility-only hold display (no override), the same block configured with `allowPinOverride: false` works. ### Settings | Setting | Description | | ----------------- | ------------------------------------------------------------------------------------------------ | | **Configuration** | Opens the configuration modal — all hold-evaluation, PIN-override, and label settings live here. | The configuration modal supports: * **Hold field** — the NetSuite field name on the customer that flags hold status (default: `creditholdoverride`). * **Hold mode** — *On* (always on hold), *Off* (never on hold), or *Auto* (evaluate the formula). * **Formula** — JavaScript-style expression evaluated against the customer record (default: `parseFloat(customer.balance || 0) > parseFloat(customer.creditlimit || 0)`). * **Allow PIN override** — Yes / No. When Yes, a PIN modal opens to clear the hold. * **PIN code field** — the NetSuite field where the manager's PIN is stored (default: `custentity_brm_pincode`). * **PIN entity type** — what entity holds the PIN: typically *employee*. * **Show label** — display the on-hold or approved label. * **Label on hold / Label approved** — the text shown for each state. ### How it works 1. Reads the selected customer from session state. 2. Evaluates hold status using the configured Hold mode and Formula. 3. Renders the configured label (with appropriate styling for on-hold vs approved). 4. If on hold and **Allow PIN override** is enabled, an override button is shown. 5. Clicking the override prompts for a manager PIN via the PIN Pad. 6. PIN is validated against the configured PIN field on an employee record. 7. Successful overrides are logged in `customrecord_brm_pin_log` with entity ID and action. 8. While the hold is active and not overridden, Submit Button refuses to complete the order. In edit mode the block shows previews of all three states (on hold, approved, no customer) so you can style with confidence. {% hint style="warning" %} The block depends on the selected customer being present in session state — it shows an empty state otherwise. Place **Customer/Vendor Selection** above it on the page. {% endhint %} ### Examples **Standard credit-hold enforcement.** Customer Hold Status with Hold mode = *Auto* and the default credit-vs-balance formula. PIN override enabled — managers can authorise sales to over-limit customers. **Always-block flag.** Hold mode = *On* for testing or for a specific workflow that should never accept transactions. **Display-only.** Hold mode = *Auto*, *Allow PIN override* = No. The hold status shows but can't be overridden — useful on a customer detail page. ### Related (Component) * [#pin-pad](#pin-pad) — The PIN entry block used in override flows. * [#customer-vendor-selection](#customer-vendor-selection) — Selects the customer whose hold status is read. * [Workflows — PIN Override](/client-admin-guide/workflow-builder-overview/pin-override.md) — The full PIN-protection setup across the workflow. *** ## PIN Pad A numeric PIN entry pad for authorising restricted actions. Configure who can authorise — by role, by named user, or both — and the block enforces those rules on PIN submission. PIN Pad pairs with **Action Button** (PIN-gated actions), **Discount Header** (PIN-gated discounts), **Customer Hold Status** (manager override), and **Submit Button** (PIN-gated submits). ![PIN Pad block as a numeric keypad with backspace and submit, ready for the user to enter a PIN](https://229581143-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAG04Mxmhw6PLRAZBvhtK%2Fuploads%2Fgit-blob-d1f427d1c084c4a07be1ed9014c4ec055be5020d%2Fpb-pin-pad.png?alt=media) ### Available in * Page modules * Order Form modules PIN Pad isn't available in Catalog, Modal, Reports, or Navigation modules. Use **Modal** + Action Button to surface a PIN prompt in those contexts. ### When to use * Workflow-wide PIN gates (e.g. clock-in / clock-out screens). * A standalone PIN authorisation page for sensitive operations. * Anywhere you need a numeric PIN input that isn't already provided by another block (Discount Header, Customer Hold Status, and Action Button each have their own built-in PIN trigger). ### Settings | Setting | Description | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | **Type** | Currently only *Module* is available — the PIN gates the whole module. | | **Authorization Role** | Pick a NetSuite role whose users are authorised. | | **Authorized Users (Managers)** | Multi-select of specific users authorised to enter a PIN here, in addition to the role. | | **Field** | Which RecordField on the page the PIN result is bound to (auto-populated from the page's RecordField components). | | **Title** | Heading text shown above the pad. Default: *Enter PIN*. | ### How it works 1. The block renders a numeric keypad. 2. The user enters their PIN. 3. The PIN is validated against either the role-based list or the explicit user list (or both). 4. If valid, the configured Field is updated with the PIN value (or a flag indicating success). 5. Downstream logic (e.g. Submit Button validation) reads the field to gate behaviour. In edit mode, the block shows a preview with a configuration summary so you can verify the role/user setup at a glance. {% hint style="info" %} For per-action PIN gating (e.g. PIN-protect a single button or a discount above a threshold), don't drop a separate PIN Pad — those blocks have built-in PIN modals. PIN Pad is for module-wide gates or standalone PIN-required pages. {% endhint %} ### Examples **Manager-only override page.** A Page module dedicated to manager actions. PIN Pad at top, Action Buttons below for void / refund / discount-override actions. Authorization Role = *Store Manager*. **Clock-in screen.** A standalone PIN Pad on a Page module — staff enter their PIN to register clock-in. Field bound to a RecordField that drives the clock-in action. ### Related (Component) * [#customer-hold-status](#customer-hold-status) — Uses PIN to authorise overriding customer holds. * [Action Components — Action Button](/client-admin-guide/getting-started/action-components.md#action-button) — For per-button PIN-gated actions. * [Workflows — PIN Override](/client-admin-guide/workflow-builder-overview/pin-override.md) — The full PIN-protection setup across the workflow. *** ## Support Case Manager A complete support-case interface inside the portal. List existing cases with filters, see status and priority badges, open a new case, and click any case for full detail. Backed by NetSuite Support Case records. Use it on a customer-facing portal page (so customers can self-serve support requests) or on an internal page (so support staff can triage and respond). ### Available in * Page modules ### When to use * Customer self-service portals where users can submit and track their own support cases. * Internal support dashboards for triaging incoming cases. * Account-management pages where the user wants visibility into their open issues. ### Settings | Setting | Description | | ------------------------ | -------------------------------------------------------------------------------- | | **Title** | The block heading displayed above the case list. | | **Show New Case Button** | Whether to render the *New Case* button. Hide it for read-only views. | | **Show Statistics** | Whether to show the stats strip — open / in-progress / closed counts at the top. | | **Configuration Modal** | Opens an advanced modal with display, list, and new-case settings (see below). | The **Configuration Modal** exposes the granular controls: * **Display**: title override, compact view, show refresh, show search, show filters. * **List**: which columns to show, page size, default sort, default filters. * **New Case**: require category, require priority, allow attachments, max attachments, max attachment size. ### How it works 1. Loads the user's accessible cases from NetSuite (filtered by their relationship — own cases for customers, team cases for support staff). 2. Renders the list with status, priority, and creation-date columns. 3. The **New Case** button opens a modal where the user fills in title, description, category, priority, and optional attachments. On submit, a new NetSuite case record is created and the user gets a confirmation. 4. Clicking a case row opens a detail modal with full case history, comments, and attachments. ### Examples **Customer self-service.** Drop Support Case onto a customer portal page with title *My Support Cases*, show stats, allow new cases with attachments. Customers can submit and track issues without contacting support directly. **Internal triage.** On a support-staff page, hide *Show New Case Button*, show stats, set default sort to *priority desc*. Staff land on the page and see their highest-priority cases first. ### Common issues * **Cases don't appear** — check that the logged-in user's NetSuite role has access to the Support Case record and the cases are linked to their entity. * **Can't create new cases** — verify the user has create permission on the Case record. Customers usually do; some employee roles don't. * **Attachment fails** — file may exceed the *Max Attachment Size* limit. Adjust in the configuration modal. ### Related (Component) * [#customer-hold-status](#customer-hold-status) — Show the customer's account-hold status, often paired with support cases. * [#entity-360-view](#entity-360-view) — The customer-overview block that often hosts a support-case panel. *** ## Related
Transaction ComponentsCustomer Field and other entity-aware blocks for Order Forms.Transaction Components
PIN OverrideThe full PIN-protection model across the workflow.PIN Override
Roles & PermissionsHow entity types map to roles and workflows.Roles & Permissions