01.software Docs

Feature Planning

Choose the smallest feature set that matches the workspace plan and operating model.

Use this page before enabling features or changing a workspace plan. The best first launch is usually the smallest useful feature set.

Feature Tokens And Effective Availability

A tenant-admin or super-admin reviews feature selection in the active workspace. Feature tokens are stable machine identifiers, not translated menu names. The minimum plan and automatic dependencies are:

Feature tokenMinimum planRequires
ecommercefree—
customersfree—
playlistsfree—
galleriesfree—
linksfree—
formsfree—
articlesfree—
documentsfree—
canvasfree—
videosstarter—
live-streamingenterprise—
communityfreecustomers
eventsfree—
membershipfreecustomers

Selected features are intersected with plan availability, then required dependencies are added. For example, selecting community or membership adds customers; neither automatically adds ecommerce. Check the effective set, automatically added dependencies, and plan-blocked selections before launch.

Enabling a feature does not grant a role, publish content, or register customer OAuth clients. App implementation belongs in the domain task guides; use this page for operating scope and availability.

Plan Availability

PlanFeature availability
FreeAll non-video workspace features: playlists, galleries, links, forms, articles, documents, ecommerce, customers, community, events, membership, canvas
StarterFree features plus videos. Existing subscriptions only; not selectable for a new subscription or plan change
BasicFree features plus videos
ProBasic feature set with higher quotas
EnterpriseAll workspace features, including live-streaming

Commerce and event ordinary email share a KST monthly pool: Free 100, Starter 1,000, Basic 1,000, Pro 3,000; Enterprise remains unlimited. Customer OTP, password reset and event cancellation are observed but excluded from ordinary limits and customer billing. Sandbox has one common 100-attempt monthly ceiling per generation, including essential email, with no external send or billing. Video is available on Starter, Basic, and Pro; live streaming is Enterprise-only.

Gallery items use images by default. For feed-style content or portfolios, each item can instead reference one video, in the same gallery order. Video items require the videos feature to be enabled and available on the workspace's current plan; they reuse the existing video upload, processing, and playback flow. Image galleries remain available on Free.

Basic and Pro are the paid plans available for new subscriptions; beyond Pro, contact sales for Enterprise. Prices include VAT, and yearly billing equals ten months.

ItemBasicPro
Monthly / yearly priceKRW 20,000 / KRW 200,000KRW 60,000 / KRW 600,000
API calls / month500,0002,000,000
Storage100GiB100GiB
Documents100,000100,000
Operator members5050
Webhook registrations1010
Ordinary email pool / month1,0003,000
  • API calls and ordinary email are monthly allowances on yearly billing too. Both reset on the first day of each KST calendar month, independent of the card billing date (subscription period).
  • Storage, documents, and webhooks are held amounts and do not reset monthly. 100GiB is 107,374,182,400 bytes.
  • API calls count /api requests that send X-Publishable-Key. Requests without a key and CORS preflight (OPTIONS) are not counted; requests that fail while processing are. The request after the limit returns 429 usage_limit_exceeded. If the usage store is temporarily unreachable, Live allows the request and Sandbox rejects it, so the API limit is not a guaranteed cost cap.
  • Storage warns at 100% of the limit and blocks uploads that add usage at the default 2x safety ceiling. Reading and deleting existing files keeps working.
  • Exceeding a lower plan's limits never triggers automatic deletion, extra charges, or upgrades. While over a limit, new creates, sends, or uploads for that item can be restricted.
  • Ten webhook registrations do not mean unlimited delivery or retries.

When API metering storage is uncertain, API requests to Live workspaces and to workspaces without a Project continue to be served. Without completeness evidence, first Enterprise monthly usage invoices are held, including apparently normal months. Existing invoices and flat subscription billing continue; missing quantities are never estimated for billing.

Feature Decisions

NeedStart withAdd later when
publish updates or guidesarticles or documentseditors need taxonomy or approval ownership
collect requestsformsa team is assigned to monitor submissions
sell productsecommercecatalog, fulfillment mode, payments, return policy, option presets, and support owners are ready
manage customer accountscustomerssupport owns verification and recovery decisions
open community spacescustomers and communitymoderation ownership is ready
run eventseventsevent owner, calendar ownership, and occurrence updates are assigned

Form submissions

Give each input field a unique name within its form. When creating a form or changing its fields, saving highlights duplicate names for correction. Existing forms can still receive title-only edits while their fields stay unchanged.

Review collected responses in Forms → Form Submissions in the Admin Panel. Form submission email notifications are unsupported in both Live and Sandbox workspaces. The form's emails settings (emailFrom, emailTo, replyTo, cc, bcc, subject and message) are retained for compatibility and have no sending effect. This also applies to existing saved settings and settings written through an API.

Dependencies

  • Community depends on customer accounts.
  • Membership requires customer accounts. Ecommerce is selected independently when you also need products and orders.
  • Membership cannot be disabled while live or incomplete memberships or pending charges remain. If the feature becomes unavailable through another change, renewals stop, existing memberships end at the paid period boundary, and customers can still view or cancel their memberships. Turning the feature back on does not restart those renewals.
  • An existing paying member keeps group benefits while renewal is unresolved for up to two hours after the paid period ends. A declined renewal, cancellation, revoked payment method, or refund ends this hold immediately. A past-due member does not receive this extra time; benefits already valid within the paid period keep their existing rule. Existing Checkout and Order prices stay fixed.
  • Plan-blocked feature intent may be saved, but it is not effective until the plan allows it.
  • Disabling unused features keeps navigation and readiness checks focused.

Preserve intent, but launch with the smallest effective set. Add features after owners, content, support, and readiness checks exist.

Use Search in the sidebar or Cmd+K/Ctrl+K to find menus and pages. Results show their menu paths, and settings can also be found by words in their descriptions.

Console Menu Names

In Console, a tenant-admin or super-admin can open Settings → Workspace → Site & branding → Menu display names and use the dedicated settings screen to rename the active workspace's menus. The names also appear in collection headings, breadcrumbs, and Cmd+K. Menus appear in the same order as the sidebar, with each section's own name in its collapsible header; each menu shows its default name next to a new-name field, and menu search lists matches with their parent paths. Save and Restore default names stay visible at the bottom while you scroll. Menu names do not change field names, content document titles, URLs, menu order, or permissions.

The Commerce Config and Branding · SEO · Business settings screens use their menu names as document headings. Select Settings (or its custom name) in the breadcrumb at the top of the screen to return to Settings.

The generated Calendar title follows its menu display name in lists, documents, and settings. Custom titles and stored titles keep their values. Screen descriptions use neutral wording, and the monthly schedule’s new event action follows the Events menu display name.

For each menu, use one single-line name of up to 40 characters for every Console UI language. Leave a name blank or reset it to restore the default name in the selected UI language. Other workspace operators see the saved names.

Account email

Saving a new email on your own Console account sends a confirmation link to that address. Open the link and confirm within one hour; your current address and sign-in remain until then. Requesting another email change invalidates the previous link.

Only the account owner can request an email change, including when a super-admin manages the account. Linked Google accounts retain their chosen address across sign-ins.

Workspace Security History

A tenant-admin or super-admin can open Settings → Workspace Access → Security history for the explicitly selected workspace. The read-only view shows recorded team member additions, removals and role changes, workspace entries, access denials and management IP policy changes.

An empty result means no displayable records match your filters on the current page. Records that cannot be displayed are excluded after pagination; check the next page for more records. An empty result does not mean no event occurred. Recording start dates are unknown; periods before collection began have no records, and access observations may be missing. Entries and access denials in Sandbox environments are not recorded. Coverage includes recorded events rather than all activity; account login and two-step verification results are excluded.

Filter by date, actor ID, event type and outcome. The default range is the last 30 days, with up to 90 days per query and 25 records per page. Dates and recorded times use the workspace timezone. Actors appear as IDs, including retained IDs for deleted accounts; names, emails, raw IPs and raw payloads are not displayed. Access details show the method, registered reason and recording mode; policy changes show the setting, change or recovery reason and recording mode.

Management IP allowlists are configured in the same Workspace Access settings. See Management IP Allowlist for credential scope and recovery.

Shared payment settings

Payment provider connections are available under Settings → Commerce → Payments → Payment provider connections without turning on Ecommerce. tenant-admin operators can register provider configuration and manage credentials in the active workspace. Secrets are never shown after saving.

  • Commerce market assignments are optional. An account with no markets is not selected for Commerce checkout.
  • Toss configuration attestation and activation are available without Ecommerce.
  • PortOne activation requires a webhook route verified for the connection's environment. Route reads and tenant-admin issue, attest, and revoke are available without Ecommerce; existing workspace and active-workspace permissions still apply.
  • Whole-connection Commerce switching still requires Ecommerce.
  • These settings do not enable a public Events payment API.

To verify a PortOne webhook route, open the connection's PortOne webhook route panel:

  1. Issue the webhook URL.
  2. Add it in the PortOne console.
  3. Send a PortOne console test call from the setting mode (test or live) that matches the connection's environment.
  4. Enter the registered URL to confirm it.

A test call can send a sample store ID, so the PortOne console may report it as failed (401). Once its signature checks out the delivery is still recorded, so continue when the panel shows Signed webhook received as Yes. If it stays No, the webhook did not arrive or its signature did not check out. Check that the URL is registered in the setting mode matching the connection's environment and that the saved webhook secret was issued in that mode.

If webhooks for real payments keep being rejected after the connection is enabled, check the following.

  • In the PortOne console, check that the store where this webhook URL is registered has the connection's store ID.
  • If the connection's store ID was mistyped, it cannot be changed after registration. Create a new connection with the correct store ID, confirm its webhook route there, and leave the old connection inactive. Connections cannot be deleted; an inactive connection is not selected for new payments, and its records are kept.
  • Within one workspace, only one connection can use the same store ID in the same payment environment. If the store ID is correct, a new connection does not help.

Rotate and re-register credentials

A tenant-admin selects the active workspace and opens its payment connection. Save or discard unsaved changes first.

Credential stateAction
ActiveRotate credentials above the document
ArchivedRestore the connection before rotation
Revoked, destruction pending, destroyedRe-register credentials above the document
  1. Open Rotate credentials and enter the new secret issued by the provider. Include the new Toss client key if it has changed.
  2. For PortOne, select the API secret or webhook secret under Secret to rotate. Run the action separately to replace both.
  3. If an error occurs, follow the reason shown in the open panel and retry. If re-entry is requested, enter the secret again in the same panel.
  4. After success, check the configuration again and enable new payments. Rotation and configuration changes clear the existing configuration check and disable new payments.

Re-registration requires a newly entered secret. For PortOne, enter both a new API secret and a new webhook secret. Check the configuration again after re-registration, then enable new payments. Duplicate account IDs are rejected even when the existing connection is inactive or archived; use the existing connection identified by the error.

Customer credits

The Console credit settings page is available only to an administrator of the selected workspace (or a super-admin) with effective ecommerce enabled; editors and viewers cannot open the settings screen or write settings/templates.

Customer credits are a supporting capability of ecommerce, with no separate paid feature token. Console credit settings start disabled. Enabling them requires the ordinary role and Customer boundaries; disabling them blocks new grants/redemption while preserving existing credit obligations. It does not change ecommerce entitlement. See the credit reference.

In Console Order detail → Purchase amount and payment records, the purchase total, credit/provider allocations at checkout freeze, credit consumed at placement and refund restorations are separate. Confirm provider collection from the transaction records below, not from the provider allocation.

Actual provider collection is displayed per successful transaction using its server-confirmed amount, currency and confirmation time, before refunds; it is not an aggregate or a net balance. Missing records or confirmation values remain unknown. See Related → Transactions for all transactions and refunds.

The allowed/blocked credit setting reflects the last confirmed save or read, independently of an unsaved checkbox. Customer balances show their evaluation time, original/grace expiry buckets and history. An available balance does not override credit settings or the ecommerce entitlement required for new redemption.

Coupons & discounts

Under Ecommerce, choose the coupon entry that matches how it is used.

  • Checkout coupons & discounts: manage coupon codes, automatic discounts, eligibility rules, and usage limits for orders.
  • Redemption coupon definitions: define single-use benefits, such as a free drink or service visit, that staff redeem for a customer without an order.

After creating a definition, your workspace server issues coupons to individual customers. Customers can view their own coupons. In Customer detail, Redemption coupons lets tenant-admin and tenant-editor operators redeem available coupons; tenant-admin operators can also void them. See issuance integration and usage boundaries.

Customer accounts

Customer accounts are created through signup or authorized server integrations. Operators with the tenant-admin or super-admin role in the active workspace can use Add customer in the customer list header to register a customer without credentials (see Manual Customer Registration). Sign-in readiness requires the customer's own verification flow. Select an existing customer in relationship fields.

Customers with a local password can reauthenticate and withdraw their account. See Customer self-withdrawal for membership restrictions and retained history.

Membership delegated payment connection

With Membership enabled, the active workspace's tenant-admin, or a super-admin with that workspace selected, can open Settings → Commerce → Payments → Membership billing connections. The connection panel shows Restore generation (current deployment) as a read-only, non-secret identifier, including before the first connection is issued.

New delegated servers obtain this value automatically through the authenticated billingCustodyContext SDK method. See encrypted billing-key storage for the server workflow. Existing integrations using an explicit generation can keep their configuration; refresh the panel after recovery and update that legacy configuration only after the platform operator announces reopening.

After recovery, complete provider re-authorization and a fresh encrypted upload and retrieval for each payment method. An unavailable value requires the platform operator to correct the deployment configuration.

Membership payment review

Membership administrators can review successful payment results that were not applied to membership activation or renewal at the time in Console under Membership → Unapplied membership payments, or from the related membership and charge detail. Each retained row shows the charge, source (dispatch, webhook, or queryCharge), and reason. The same payment may appear in multiple rows across result sources, and records are retained regardless of subsequent handling. These records are for review; refunds remain workspace-operated.

A late paid result for a voided expired-setup first charge is retained with reason voided. The Membership remains expired.

Embedded Admin

Workspace administrators can configure one embedded app with exact execution-role opt-in. tenant-editor and tenant-viewer operators see only the authorized execution screen; the receiver must also opt in and enforce feature permissions. See Embedded Admin.

Export policies

After explicitly selecting a workspace, administrators can use its document's Exports tab to set form-submission current-page CSV and order carrier CSV/XLSX independently to built-in, disabled, or export with app. Unset uses built-in export; there is no workspace default or inheritance.

Export with app:

  • requires an action registered for that collection, an enabled app, and file-download opt-in
  • can be run only by administrators, with up to 100 explicitly selected IDs
  • blocks later app exports when the app is disabled, its action is removed, or downloads are revoked; the saved policy does not change
  • never switches to a built-in file after a failure

For built-in form CSV, set rows per page to 100 or fewer, including when using a ?limit= URL. Sandbox creation does not copy these policies; both collections start with built-in export.

Built-in form CSV is in the list’s ⋮ menu. For form submissions, disabled-export guidance and the export-with-app control appear in the list body, where the launched app also opens. Order carrier files are exported from the selection toolbar after selecting orders; their disabled-export guidance and export-with-app control also appear in that toolbar, and the launched app opens below it.

This setting does not prevent all data egress. These remain available and outside this control:

  • fulfillment-import-errors.csv, product-import-errors.csv, and import templates. Error CSV can contain order numbers, product handles, input values, and error prose; product templates can include field-configuration metadata.
  • Ordinary API reads, media downloads, and canvas PNG.

An app launch is not evidence of customer-side encryption or of a file saved on a device. The external app must implement its own data authorization and encryption.

Next Actions

Event organizers can enable Verify registration email on each event. Guests enter an emailed code before a registration or seat is created. The default stays off for existing integrations. Confirmation emails include a cancellation link and have a recipient limit that preserves successful registrations.

Review paid periods left unprovided by withdrawal under Membership → Unprovided paid periods—workspace action required. Administrators can assign handling and change its status. Amounts require confirmation; handling updates do not change membership or payment records or execute refunds.

On this page