# Automatic System Role Naming for IAM Applications

## Task
Rename system roles meaningfully based on their contained permissions.

## Understanding Data Structure
**Input data consists of:**
- **SYSTEM ROLES table**: Roles with IDs, permissions and assigned persons
- **PERMISSIONS table/XML**: Detailed permission information
- **Person context**: Job titles as functional hints

## Naming Logic

### 1. Application name as prefix with improved formatting
- **Rule**: Every new role name starts with the application name
- **Format**: `ApplicationName-Function-Description` (with hyphens instead of underscores)
- **Examples**: 
  - `ERP-Production-Management`
  - `CRM-Customer-Full-Access`
  - `Finance-Accounting-Basic`

### 2. Word separation and readability
**Separate compound terms meaningfully:**
- `CustomerManagement` → `Customer-Management`
- `ProductionPlannerAccess` → `Production-Planner-Access`
- `AdministratorRights` → `Administrator-Rights`

**Naming conventions:**
- Use hyphens (-) for word separation
- Capitalize first letters of main words
- German and English terms can be mixed
- Maximum 3-4 word segments after the application name

### 3. Universal functional analysis of permissions
**Analyze permission patterns systematically:**

**Determine access level:**
- Read-only permissions → `Read-Access` or `View-Only`
- Write permissions → `Management` or `Edit-Access`
- Comprehensive permissions → `Full-Access` or `Administration`
- Special functions → `Special-Access` or function-specific name

**Identify functional area (adaptive):**
- Analyze permission names and descriptions
- Recognize recurring terms and patterns
- Identify main functional areas of the application
- Group similar permissions logically

**Recognize segmentation/specialization:**
- Regional/geographical divisions
- Department/team-specific access
- Project/product-specific permissions
- Hierarchy-based differences
- Time/status-based restrictions

### 4. Systematic permission analysis
**Compare permission sets between roles:**
1. Collect all permission IDs per role from SYSTEM ROLES table
2. Look up details in PERMISSIONS data
3. Identify commonalities and differences
4. Recognize patterns and logical groupings
5. Derive main function and specification

### 5. Person context as validation
**Job title of assigned person as functional hint:**
- Executives + comprehensive rights → `Manager-Full-Access`
- Coordinators + segmented rights → `Coordinator-Area`  
- Specialists + domain-specific rights → `Specialist-Function`
- Standard employees + basic rights → `Employee-Standard`

### 6. English naming conventions with hyphens
**Use English terms with clear separation:**
- Full-Access, Read-Access, Management, Edit-Access, Administration
- Standard, Basic, Advanced, Special, Premium
- Manager, Coordinator, Specialist, Employee, User
- For domain-specific terms: retain original technical terms

### 7. Adaptive application logic
**Recognize application type from permissions:**
- **CRM/Sales systems**: Customers, Leads, Contracts, Partners
- **ERP systems**: Production, Warehouse, Purchasing, Sales  
- **HR systems**: Personnel, Vacation, Salary, Applications
- **Finance systems**: Accounting, Controlling, Finance
- **Project systems**: Projects, Tasks, Resources, Time
- **Domain-specific systems**: Use domain terminology

### 8. Ensure uniqueness
- Every generated name must be unique
- For similar roles: distinguishing features in separate word segments
- For conflicts: descriptive differences instead of numeric suffixes

## Quality Guidelines
- **Length**: 25-50 characters total (including hyphens)
- **Word segments**: 2-4 segments after the application name
- **Clarity**: Each word segment must be understandable
- **Consistency**: Similar permission patterns → similar naming conventions
- **Readability**: Name should be understandable without documentation
- **Professional**: Respect industry-specific terminology

## Analysis Approach
1. **Identify application type**: What kind of system based on permissions?
2. **Cluster permissions**: Group by recognized functional areas
3. **Determine access level**: Scope and depth of respective role
4. **Recognize patterns**: Recurring terms and logical structures
5. **Check person context**: Validate against job title and position
6. **Construct names**: Application + Function + Specification (separated by hyphens)
7. **Check uniqueness**: No duplicates, clear differentiation

## Output Format
**Exactly this format - no comments:**
```
SystemRole_4_0 = ApplicationName-Function-Name
SystemRole_4_1 = ApplicationName-Other-Function
SystemRole_4_2 = ApplicationName-Third-Function
SystemRole_4_3 = ApplicationName-Fourth-Function
```

## Universal Interpretation Aids
**Common permission types (cross-industry):**
- `User/Benutzer` + `Read/Lesen` → `Basic-Read-Rights`
- `Admin/Administrator` → `Administrator-Rights` or `Full-Access`
- `Manager/Leiter` → `Manager-Management`
- Regional/Department designations → `Regional-Access` or `Department-Management`
- Function-specific terms → Direct adoption with English adaptation
- Hierarchical gradations → `Standard`, `Advanced`, `Premium`, `Full-Access`

## Example Naming (universal)
**Different application types:**
```
CRM-System:
SystemRole_4_0 = CRM-Customer-Full-Access
SystemRole_4_1 = CRM-Lead-Management

ERP-System:  
SystemRole_4_0 = ERP-Production-Manager
SystemRole_4_1 = ERP-Warehouse-Employee

Finance-System:
SystemRole_4_0 = Finance-Accounting-Full-Access
SystemRole_4_1 = Finance-Controlling-Basic

HR-System:
SystemRole_4_0 = HR-Personnel-Administrator  
SystemRole_4_1 = HR-Employee-Self-Service
```

Analyze the specific application and permission structure in the input data and generate correspondingly adapted system role names.

---

## INPUT DATA