PlcConsole
Remote Manual · Workflows

Operational recipes

Follow complete procedures that cross several screens, then verify the resulting state and audit evidence.

Remote manualOnboard tenantBring site onlineGrant accessInvestigateRotateOffboard
Recipe 1

Onboard a tenant and its first administrator

This is a platform-admin workflow. It creates the organization boundary and transfers normal administration to the invited tenant administrator.

Before you begin

  • Confirm the legal or operational tenant name.
  • Obtain the first administrator's email through an approved channel.
  • Confirm invitation email delivery is enabled or arrange trusted manual delivery.

Expected result

The tenant begins disabled with an invitation pending. Acceptance creates the tenant administrator, seeds the tenant role templates when needed and activates the tenant.

Procedure

  1. Open Tenants as a platform administrator and choose Create tenant.
  2. Enter the tenant details and invited administrator email, then submit.
  3. Confirm the directory shows Invite pending. Resend only when delivery genuinely needs to be repeated.
  4. After acceptance, select the tenant to enter its context and confirm the header shows the expected Acting on behalf of value.
  5. Open Tenant and verify that the administrator appears in the local-admin table.
If it fails: distinguish mail delivery from invitation acceptance. A delivered message can still contain an expired or already-used link. Create or resend only through the tenant directory and verify the resulting event in audit history.
Recipe 2

Bring a site online through a site agent

Create the physical scope first, then the outbound agent identity, then the PLC record that will use that route.

Before you begin

  • Choose a supported operating system and CPU architecture for the site host.
  • Confirm outbound HTTPS and WebSocket access to the control plane.
  • Know the PLC host, port and station ID as reachable from the agent host.
  • Decide which command policy should constrain register access.

Expected result

The agent row is Active and Connected, its heartbeat remains current, the reported software version is visible and a test against the registered PLC completes through the managed route.

Procedure

  1. Create the Site with connectivity mode SITE_AGENT.
  2. Open Site agents, create an agent for that site and copy the issued credential into the protected site configuration.
  3. Expand Agent installer, download the matching archive, SHA-256 checksum and Sigstore bundle, then verify both integrity and signature.
  4. Install and start the agent using the target-specific README packaged in the archive.
  5. Return to the agent catalog and confirm the connection state. Expand the row to inspect version, credential dates, connection observations and the last error.
  6. Create the PLC under the same site, assign its policy and run Test or Status.
If it fails: Awaiting connection means no authenticated session has been observed. Disconnected means there is no live session. Heartbeat stale is reserved for a live session whose heartbeat is overdue. Check the last error and agent logs before rotating credentials.
Recipe 3

Grant one operator read access to one PLC

Use a role for the reusable baseline and a scoped assignment for the target. A command policy can then narrow which registers are readable.

Before you begin

  • The PLC must exist in the correct tenant and site.
  • The user must have an active tenant account with a persisted role.
  • Decide whether the scope applies to one PLC, one site or the whole tenant.
  • Define the required register families and ranges.

Access calculation

Role and direct-user assignments are additive. Any matching grant may authorize the operation. For register reads, the PLC's assigned command policy must also contain a matching READ rule covering every requested address.

Procedure

  1. Create or select the user's role and give it only the normal baseline permissions.
  2. Create a permission assignment for device.view at PLC scope so the device is visible.
  3. Create assignments for device.test, the required status permission and device.register.read at the same scope.
  4. Create or edit a command policy with READ rules for the approved Fatek families and optional ranges.
  5. Assign the policy to the PLC.
  6. Sign in as the user or inspect the user's mobile operator context, confirm only the intended PLC is visible and perform an allowed read.
  7. Verify the command and outcome in audit history.
Do not use a narrower assignment to revoke a broader grant. The model has no deny assignments. Remove or archive the broader grant if it should no longer apply.
Recipe 4

Investigate a denied or failed PLC command

Start with the shortest dashboard window that contains the symptom, then follow the event into tenant-visible audit evidence.

Observed outcomeFirst questionsLikely next screen
DeniedWas the PLC visible? Was the operation granted at an applicable scope? Did the command policy cover the family and range?Users, roles and permissions; Command policies; Audit
FailureWas the site route available? Was the PLC reachable? Did execution time out or return a protocol error?Sites and PLCs; Site agents; Agent failures; Audit
No activityIs the correct tenant and time window selected? Is an active filter hiding the record?Operations; Common controls

Procedure

  1. Select the shortest dashboard window that still contains the event.
  2. Open Denied commands or Failed commands and filter by user, PLC, site or time as appropriate.
  3. Expand the row and retain the correlation identifier.
  4. For a denial, verify visibility and effective permission before inspecting the assigned PLC policy.
  5. For a failure, verify agent or VPN reachability, PLC status and the returned execution detail.
  6. Open Audit, filter to the relevant event and compare request attributes with result attributes.
  7. If infrastructure logs are needed, search the same time interval and correlation identifier without copying credentials or tokens.
Recipe 5

Rotate an agent credential or service-account token

Rotation immediately replaces the current authentication material. Prepare the consumer so the new secret can be installed without ambiguity.

Planned rotation

  1. Identify the exact agent or integration and its owner.
  2. Open the rotate confirmation and understand that the existing credential will be invalidated.
  3. Confirm rotation and copy the replacement from the one-time display.
  4. Transfer it directly into the target secret store or protected configuration.
  5. Restart or reload the consumer and verify successful authentication.

Suspected compromise

  1. Revoke the exposed credential immediately.
  2. Review authentication and operational audit events for unexpected activity.
  3. Issue replacement material only after the target environment is trusted.
  4. Confirm the old material can no longer authenticate.
If the replacement is lost: it cannot be recovered from the UI. Rotate again and store the newly issued value immediately. Never place credentials in screenshots, repositories, tickets or ordinary application logs.
Recipe 6

Retire access without losing evidence

  1. Identify dependent users, roles, permission assignments, PLCs, agents or integrations before changing lifecycle state.
  2. Use Disabled where a temporary pause is supported and return is expected.
  3. Revoke active credentials or sessions when trust must end immediately.
  4. Archive the record only when it should leave normal operation permanently.
  5. Confirm the record no longer appears in active lists and review the corresponding audit event.

Archive is a soft-delete style lifecycle action. It preserves history but may make dependent access unavailable, so use the confirmation warning as the final dependency check.