Permission Health

• Nobody knows why a permission exists.

  Finding out why someone can change a field means digging manually through roles, groups and rules.

• Clean-ups come undone.

  A permission structure that was fixed once quietly widens again.

• Findings wait for decisions.

  Hundreds of records go for approval one by one, and who decided what, and when, gets lost.

• Requests close without proof.

  A task counts as closed when the consultant says "done".

• The "why" is answered on screen.

  The chain of person, group membership, role, permission and target population reads on one page; every permission row shows whose records it applies to.

• Regressions get noticed.

  Snapshots are compared; widened, narrowed and unmeasurable changes are listed separately.

• Decisions are made once.

  Decisions are made per finding type and outliers become exceptions; the decision-maker and time are recorded, and an expired decision brings the finding back.

• Requests close with proof.

  The consultant receives a written work order; the task closes when the next data pull verifies the change.

• Risky combinations become visible.

  Conflicting permissions held by the same person are screened with segregation of duties (SoD) rules.

• Unknown is not counted as clean.

  Answers are split into "none", "not asked" and "no answer"; an empty query never produces a deletion proposal.

1. 1

   Read and snapshot

   SuccessFactors is only read; every pull is stored as a snapshot.

2. 2

   Rule engine

   39 rules run deterministically; every finding is tagged "measured" or "needs confirmation".

3. 3

   Decision log

   Decisions are made per finding type; who and when are recorded.

4. 4

   Work order and verification

   The consultant gets written instructions; the request closes with the next snapshot.

The permission calculation is cross-checked against SuccessFactors' own permission query (checkUserPermission). The measurement was made in a single customer environment on 126 samples; 119 matched (94.4%). Every release passes automated tests, and the panel is verified to give the same answers on SQLite and PostgreSQL.

• No writes.

  SuccessFactors access is read-only; the panel has no role deletion or assignment, people make the change.

• The panel is not exposed.

  It is reachable only from the machine it is installed on; data stays in that machine's data store.

• No data goes to AI.

  No AI service is called at runtime; all data, including employee names, stays in the local engine.

• The decision trail cannot be deleted.

  The decision-maker and time are mandatory; a signed approval cannot be deleted.

• What is installed?

  A Python engine, the panel interface and a SQLite or PostgreSQL data store, in the customer's environment.

• What does it connect to?

  The SuccessFactors OData endpoint, with basic authentication or OAuth.

• What we need from you.

  A read-only API user with the "Manage Role-Based Permission Access" permission; a group membership report and the MDF permission matrix; the people who will decide on findings. No write access is required.

• Coming next.

  A versioned installation with a .NET back end and a Docker image; nightly automatic pulls, ticket integration, SLAs and escalation. These do not work yet and have no date.