Action Profiles

An action profile decides what a user may do in SBN. Every menu, program and button carries an action number, and a profile is the list of action numbers switched on. Users are given profiles, not permissions one at a time — which is why "your action profile" is the answer whenever SBN refuses something. Profiles are built in #1502, attached to users in Personnel (#1811), and read back in Users (#1501).

How the module progresses

1. Read a profile and work out what its users can reach.
2. Build a new profile from an existing one.
3. Grant and revoke individual actions — safely.
4. Set the profile-level gates.
5. Attach profiles to a user and restrict them to branches and dealers.
6. Diagnose a refusal.

1. Read a profile and work out what its users can reach

Task: open a profile in #1502, read its settings row, and find any single action inside it.

The list and the detail. The upper pane lists every profile with the settings that apply to the whole profile (section 4). Zoom [F10] opens the Detail View beside it — the Main Menu expandable down to function-key level, plus Other Actions, the complete list by number. Tear [F7] floats it into its own window.

Two profiles SBN ships with. ALL holds every function and belongs only to the person who set the system up; CSSA is the first-login profile, carrying the main features including profile setup. Clone from these — do not hand them out.

Two ways to look at the same thing. The Action / Menu switch changes the view, not the content. Menu lists actions by where they sit in the menu tree — the view for "can this user get to Data Entry at all". Action lists them by number — the view for "can this user press this button".

Two layers of access. Reaching a program needs the menu leading to it, or the right to jump to a program number (the SBN Fundamentals & Navigation module's GoTo). Doing something inside it needs that function's own action — in Dispatch (#537), Transfer Alarms is 537/105.

Worked example (Branch TRAIN): open #1502, select CSSA, Zoom, and find Data Entry (#559) in the Menu view. Switch to the Action view and search 537/105 — highlight the Sublevel menu, [ALT+F2] to search by name or number, [ALT+F3] for the next match. Say what a user without that action loses.

Guided practice: with the detail torn into its own window, name three things CSSA reaches that a monitoring operator never needs.

Independent practice: pick any profile and, without changing it, name two programs its users can open and two Dispatch functions they cannot — and which view told you each.

2. Build a new profile from an existing one

Task: create a working profile by cloning one that is close, and know why a profile sometimes refuses to delete.

Templates do the copying. New [F3] opens the lower pane: Name, Description, Default Program (what opens at login), Default on Search (what opens after a search), then Template (1) — the profile closest to what you want. Template (2) and Template (3) merge further profiles' actions on top. The profile must itself be allowed into whatever you name in Default on Search.

You cannot hand out more than you hold. The picklists only offer profiles whose actions are all inside your own — so nobody can grant themselves a way in through a profile they cannot read.

Deleting. Delete [Shift+F10] and confirm — but a profile assigned to a user will not delete; detach it from the users first.

Worked example (Branch TRAIN): create TRNOP — Description "Training operator", Default Program 559, Template (1) CSSA. Save, Zoom, and confirm it came out like its template.

Guided practice: create TRNSUP using TRNOP as Template (1), and name one thing a supervisor needs and an operator does not.

Independent practice: try to delete a profile already assigned to a user and read what SBN does. Then say which profile you would clone for a data-entry clerk who never touches the Alarm Queue — and why not ALL cut down.

3. Grant and revoke individual actions — safely

Task: switch single actions on and off, on one profile or across many, without locking yourself out.

Steps:

1. Select the profile and Zoom [F10].
2. Set Action / Menu — Menu to open a route, Action to reach one function.
3. Change Record [F2], then mark the actions you want on and clear the ones you want off — or expand to one action category and take Spreadsheet [F12], which grids that category against every profile at once.
4. Save, and have the user log off and back on — the menu is rebuilt at login.

The rule that bites administrators. You may only grant or revoke actions that are in your own profiles — revoke one from the only profile you hold and you have removed your own right to grant it back. The protection is a second copy: keep a duplicate of ALL, hold both, and edit the copy.

Safe change practice. Change a clone, not a profile people are working on. Revoke the narrow action before the whole menu, and test on a spare user rather than an operator mid-shift. The Log tab records date, time, module, status and user for every change.

Worked example (Branch TRAIN): on TRNOP, confirm Data Entry (#559) is reachable in the Menu view, then revoke Transfer Alarms 537/105 in the Action view. Save, and read the Log tab entry it wrote.

Guided practice: open Spreadsheet [F12] on one action category, compare TRNOP and TRNSUP, and grant one action to TRNSUP only.

Independent practice: revoke one action from TRNOP and write down, before testing, the exact symptom — which screen, which button, at what moment. Then say what they would have seen had you revoked the menu instead.

4. Set the profile-level gates

Task: set the settings that apply to everyone on the profile, and predict what they do to a user with two profiles.

Where the user starts. Default Program opens at login, Default on Search after a search, and the Prg 559 / 562 / 548 Tabs fields set tab order in Data Entry, Marketing and Contract Master.

Max Test Days. The most days a user on this profile may put an installation into Test or Runaway from the Insert Test tab of #559 (the Test Mode module). Blank means no limit; ask for longer and SBN refuses the insert outright. When a user holds several profiles the highest Max Test Days wins — the tightest profile does not restrain the loosest.

Skills and Dynamic Skills. Up to twenty of each, deciding which alarms this profile's users see in the Alarm Queue and may handle in Dispatch (those two modules). A user carries skills of their own too, so check both places when an alarm goes missing.

Settings that need a fresh login. Alarm Log View and Generating Source take effect only after log off and log on. Temp Texts Expire caps how far ahead temporary text may expire in the Texts tab, and bites only where the company has the temporary-text expiry rule on.

Worked example (Branch TRAIN): set Max Test Days to 1 on TRNOP, leave it blank on TRNSUP, and give TRNOP one skill from the list.

Guided practice: set Alarm Log View on TRNOP, save, and say exactly when the user would first see it; then set Default Program to 559 and say what that changes.

Independent practice: a user holds TRNOP (Max Test Days 1) and TRNSUP (blank) and asks for a five-day test. Say whether it is allowed and why, then name the profile you would edit to stop it.

5. Attach profiles to a user, and restrict them to branches and dealers

Task: put profiles on a user, add the branch and dealer restrictions, and say what only an administrator can do here.

The chain, in order. A new user needs a database login first — Add User Login (#564), which asks for the database administrator's credentials before it creates the name and password. Then the master record in Personnel (#1811), whose Users tab attaches the profiles; Users (#1501) reads and edits that assignment afterwards. Each step needs a login holding the actions for it, and the first needs the database administrator's password too — so a new user cannot be made from an operator's seat.

Profiles are cumulative. Action (1) is the primary profile; the further Action fields — up to ten profiles on one user — add on top. Access is the sum, never the smaller: a user may do anything any of their profiles allows, so adding a profile can only widen a user, never narrow one. That is why profiles are built as roles to be combined (operator, data entry, supervisor add-on) rather than one giant profile per person — and why removing a right means checking every profile the user holds. Put the profiles that matter first; the everyday permission check reads Action (1) to (5).

The Profiles section — separate restrictions, each set in its own program:

A branch profile is a named list of branch matches, used either as the list the user is allowed or the one they are denied. Which of these filters the Alarm Queue depends on how the company is set up, so check rather than assume. Last Login says whether a user has picked up your change.

Worked example (Branch TRAIN): create TRNTEST — login in #564, master record in #1811, then in #1501 set Action (1) to TRNOP and the Branch profile to one covering Branch TRAIN. Log in as TRNTEST and read the menu you get.

Guided practice: add TRNSUP as TRNTEST's Action (2), name one thing that became possible, then read Last Login and say what it proves.

Independent practice: change TRNTEST's branch profile so Branch TRAIN is excluded, predict what disappears and what stays, then test and explain any difference.

6. Diagnose a refusal

Task: given "SBN will not let me do it", find which layer refused.

Work down the layers. Each refuses for its own reason:

1. The assignment — in #1501, read Action (1) to (5). The wrong primary profile is the commonest answer.
2. The route — in the Menu view, is the menu leading to the program on? Without it the program is reachable only by number.
3. The function — in the Action view, search the action number with [ALT+F2]. This is the layer behind "the screen opens but the button does nothing".
4. The gates — Max Test Days for a refused test insert, skills for alarms that never appear.
5. The restrictions — branch, dealer, terminal. They hide records, not buttons: the program opens and the installation or alarm is simply not there.

Two things to rule out first. The menu is built at login, so a user who never logged off is the most-diagnosed non-problem in SBN. And if SBN refuses you while granting, you are granting something not in your own profiles — the target profile is fine.

Worked example (Branch TRAIN): as TRNTEST, try to put MILLER (TRA-00002) into test for three days. Read the refusal, then find the setting behind it in #1502 and say which profile it came from.

Guided practice: TRNTEST reports that alarms other operators are treating never reach their queue. Walk the five layers aloud, name the two that could produce that symptom, and how you would tell them apart.

Independent practice: an operator says "I can open Dispatch but I cannot transfer an alarm, and one of my customers has vanished from search." Diagnose in order, name the two separate causes, and state the safest first change — and why not simply ALL.

7. Quick reference

One-liners: Menu view answers "can they get there", Action view "can they press it" · Action (1)–(5) add up, never subtract · the highest Max Test Days wins · you can only grant what you hold · never edit ALL — edit a duplicate · a profile assigned to a user will not delete · the menu is rebuilt at login · restriction profiles hide records, action profiles hide buttons.