SoD — Activities
The Activities screen lists the named activities within each business process. One line per (Application, Process, Activity). An activity is the atomic unit of the SoD analysis — for example Create vendor, Approve payment, Post journal entry.
The Matrix combines pairs of activities to express incompatibilities. The Objects screen attaches each activity to the source-system programs that back it.
At a glance
Goal of the view
- Define the atomic actions the SoD model reasons about.
- Stable identifiers across audit cycles — Activity ID feeds the matrix and the conflict reports.
- One row per granular action. Keep the activities tight: Create vendor and Modify vendor are different activities, not one combined entry.
Columns
| Column | Source | What it tells you |
|---|---|---|
| Application ID | ACT_APPS_ID — application. | The application the activity applies to. |
| Process ID | ACT_PROCESS_ID — links to Process. | The business process the activity belongs to. |
| Activity ID | ACT_ID — short identifier. | Reference used by Matrix, Objects and the Conflicts views. |
| Activity Name | ACT_NAME — friendly label. | Human-readable name. |
Edit dialog
Click Add to declare an activity, or double-click a row to edit. The dialog is a single form.
| Field | What to enter |
|---|---|
| Application | Drop-down of declared applications. |
| Process | Drop-down filtered to the processes of the chosen application. |
| Activity ID | Short identifier (e.g. VEND-CR, PAY-APV). Referenced by Matrix and Objects. |
| Name | Friendly label. Surfaces on the Details and Proven conflict screens. |
Tips & best practices
- Name from the business angle. Use verbs (Create, Modify, Approve, Post) — easier to discuss with the business owners than technical names.
- Keep activity names stable. Renaming breaks the comparison between SoD reports across cycles.
- Group activity definitions per process. Activities that span two processes typically point to a misclassification of either the activity or the process.