Skip to main content

Enhanced auditing capabilities

Purpose​

This reference describes the event payload data your audit data can contain. Enhanced auditing is available on both iGrafx Cloud and on-premises installations; only the way you access and retrieve the data differs between the two.

Enable enhanced auditing​

Enhanced auditing is enabled by default on both Cloud and on-premises installations.

  • Cloud: To turn the feature on or off, go to Administration → Support and select the System Information tab. Under Audit Settings, set Enable enhanced audit service.
  • On-premises: The platform writes audit events to local log files on the application server. See File-Based Audit Logging for where the files live, how rollover works, and how to access them.

Access the audit data​

info

Cloud only

The REST API described below is only available on iGrafx Cloud instances. On-premises installations expose the same enhanced audit data through local log files — see File-Based Audit Logging for details.

You can query the audit information via the REST API of the iGrafx Process Design application. The general endpoint to retrieve your audit information is

https://YOUR_SUBDOMAIN.igrafxcloud.com/api/auditevents

The endpoint requires the Access Support Features server permission.

Calling it without any query parameters returns the last 24 hours of audit information, newest event first, in the data format outlined below under General payload structure.

Query parameters​

ParameterValueDefaultWhat it does
secondThresholdWhole number of seconds86400 (24 hours)Sets the length of the time range, counted back from eventsBefore — or from the time of the request when eventsBefore is omitted.
eventsBeforeUTC timestamp in ISO-8601 format with a Z suffix, for example 2026-04-01T00:00:00ZThe time of the requestSets the end of the time range. secondThreshold is subtracted from this timestamp to give the start of the range.
eventTypeOne or more event types, such as create-userAll event typesReturns only events whose type matches one of the values given. For the values, see the Event Type column under Available event data.
eventCategoryOne or more event categories, such as SECURITYAll categoriesReturns only events whose category matches one of the values given. For the values, see the Category column under Available event data.

How the parameters behave:

  • Both ends of the time range are inclusive.
  • To pass more than one value to eventType or eventCategory, either separate the values with commas — ?eventType=create-user,delete-user — or repeat the parameter — ?eventType=create-user&eventType=delete-user. Either form returns events matching any of the values given.
  • Use one form or the other for a given parameter. A request that mixes them treats the comma-separated values as a single value, which matches no events.
  • An event has to satisfy every parameter you send: it must fall inside the time range, match one of the eventType values, and match one of the eventCategory values. Omit a parameter to drop that restriction.

General payload structure​

Every audit event has the following data structure, plus custom data relevant to the specific type and category of the event. This section describes the general structure; the tables under Available event data show examples of specific audit events.

Basic audit event payload​
{
  "uuid": "558ff7b4-7fd2-459c-9b2d-4a3d5d0fc306",
  "eventType": "loginsuccess",
  "eventCategory": "SECURITY",
  "eventData": {},
  "timestamp": "2023-08-08T04:26:58.919+00:00",
  "principal": "firstname.lastname@company.com",
  "authenticationType": "OAUTH2",
  "hostname": "abcdef123456",
  "platformVersion": "18.3.1.925-develop",
  "platformUuid": "fdc8450e-7774-4c8c-88ee-a0f6162aa616",
  "tenantId": "abcd1234"
}

The fields are as follows:

Field nameContent/Purpose
uuidContains a unique identifier for the event
eventTypeSpecific event type (see Event Type column in the below table)
eventCategoryCategory for the event (see Category column in the below table)
eventDataA custom payload that is different per event (see the below table)
timestampThe timestamp of the event, either as ISO-8601 string or numeric timestamp
principalThe authenticated user or entity that triggered the event
authenticationTypeThe type of authentication the principal was using during this event (see Authentication Type column in the below table).

The authenticationType property gives you security-relevant information.
hostnameThe name of the host of the Process DesignProcess Design The discipline of explicitly modeling business processes to document, analyze, and optimize them. In Process360 Live, process design is the authoring side that complements mining's data-driven view. instance.

The hostname property is mainly implemented for internal purposes and customers with multiple deployments/servers. It isn't relevant for most customers.
platformVersionThe version the Process DesignProcess Design The discipline of explicitly modeling business processes to document, analyze, and optimize them. In Process360 Live, process design is the authoring side that complements mining's data-driven view. app was running at the time of the event
platformUuidContains the unique identifier of the Process DesignProcess Design The discipline of explicitly modeling business processes to document, analyze, and optimize them. In Process360 Live, process design is the authoring side that complements mining's data-driven view. instance
tenantIdThe unique tenant identifier for the Process DesignProcess Design The discipline of explicitly modeling business processes to document, analyze, and optimize them. In Process360 Live, process design is the authoring side that complements mining's data-driven view. instance (if present).

The tenantId property is mainly implemented for internal purposes and customers with multiple deployments/servers. It isn't relevant for most customers.

Authentication type​

authenticationTypeDescription
BASIC*This authentication type signifies a “basic” sign on with a username and password
OAUTH2When the principal uses OAuth2 to authenticate with Process DesignProcess Design The discipline of explicitly modeling business processes to document, analyze, and optimize them. In Process360 Live, process design is the authoring side that complements mining's data-driven view.
SAMLWhen the principal uses SAMLSAML An XML-based standard for exchanging authentication and authorization data between an identity provider and a service provider. Process360 Live supports SAML 2.0 for SSO. to authenticate with Process DesignProcess Design The discipline of explicitly modeling business processes to document, analyze, and optimize them. In Process360 Live, process design is the authoring side that complements mining's data-driven view.
APP_TOKENiGrafx Access Management Service
API_KEYWhen the principal uses an API Key to authenticate with Process DesignProcess Design The discipline of explicitly modeling business processes to document, analyze, and optimize them. In Process360 Live, process design is the authoring side that complements mining's data-driven view.
SYSTEMUsed for internal/automated actions of Process DesignProcess Design The discipline of explicitly modeling business processes to document, analyze, and optimize them. In Process360 Live, process design is the authoring side that complements mining's data-driven view.

* If the authentication type can not be determined, the BASIC authentication type will be used.

Available event data​

In addition to the generic fields listed above, each action may carry additional information:

USER_MANAGEMENT​

User Action

Event Type

Category 

eventData payload

Create Local User In Platform

create-user

USER_MANAGEMENT

 
"eventData": {
  "user": {
    "id": "637",
    "loginName": "firstname.lastname@company.com",
    "firstName": "Firstname",
    "lastName": "Lastname",
    "email": "firstname.lastname@company.com"
  }
}

Update User Details In Platform

update-user

USER_MANAGEMENT

 
"eventData": {
  "userBefore": {
    "firstName": "Old firstname",
    "lastName": "Old lastname",
    "loginName": "oldfirstname.oldlastname@company.com",
    "userDirectoryType": "LOCAL",
    "id": "637",
    "email": "oldfirstname.oldlastname@company.com",
    "enabled": "true"
  },
  "userAfter": {
    "firstName": "New firstname",
    "lastName": "New lastname",
    "loginName": "newfirstname.newlastname@company.com",
    "userDirectoryType": "LOCAL",
    "id": "637",
    "email": "newfirstname.newlastname@company.com",
    "enabled": "false"
  }
}

Delete User In Platform

delete-user

USER_MANAGEMENT

 
"eventData": {
  "user": {
    "loginName": "firstname.lastname@company.com",
    "firstName": "Firstname",
    "lastName": "Lastname",
    "userDirectoryType": "LOCAL",
    "id": "637",
    "email": "firstname.lastname@company.com",
    "enabled": "true"
  }
}

OBJECTS​

User Action

Event Type

Category 

eventData payload

Navigate to Object Tab in Platform Model Area

load-object-tab

OBJECTS

 
"eventData": {
  "objectId": "568331",
  "repository": "repo",
  "version": "-1",
  "tab": "itemprops"
}

Bulk operation requested

create-bulk-operation

OBJECTS

 
"eventData": {
  "bulkOperations": [
    {
      "bulkOperationType": "Relationship_Remove",
      "objectIds": [
        223,
        1245
      ],
      "changeParameters": [
        {
          "relationshipType": "RACIC",
          "slot": 2,
          "targetObjectIds": [
            1236
          ]
        }
      ]
    },
    {
      "bulkOperationType": "Relationship_Add",
      "objectIds": [
        223,
        1245
      ],
      "changeParameters": [
        {
          "relationshipType": "RACIC",
          "targetObjectIds": [
            193,
            196
          ]
        }
      ]
    }
  ]
}

DIAGRAMMING​

User Action

Event Type

Category 

eventData payload

View Web Diagram

view-diagram-data

DIAGRAMMING

 
"eventData": {
  "repository": "testRepo",
  "objectId": "9197",
  "version": "0"
}

NARRATIVE​

User Action

Event Type

Category 

eventData payload

View Full Diagram Narrative

view-full-narrative

NARRATIVE

 
"eventData": {
  "repository": "repo",
  "objectId": "9375",
  "objectVer": "0",
  "narrativeId": "21",
  "version": "0"
}

View Diagram SOP Narrative

view-sop-narrative

NARRATIVE

 
"eventData": {
  "repository": "repo",
  "diagramId": "9375",
  "diagramVersion": "6",
  "narrativeId": "21",
  "narrativeVersion": "0"
}

View Shape Narrative

view-shape-narrative

NARRATIVE

 
"eventData": {
  "repository": "repo",
  "diagramId": "7451",
  "diagramVersion": "1",
  "narrativeId": "1327",
  "narrativeVersion": "0",
  "shapeId": "121"
}

View Path Narrative

view-path-narrative

NARRATIVE

 
"eventData": {
  "repository": "repo",
  "diagramId": "8906",
  "diagramVersion": "2",
  "narrativeId": "21",
  "narrativeVersion": "0",
  "pathId": "1",
  "shapeIds": {
    "shape1": "4",
    "shape2": "6",
    "shape3": "7",
    "shape4": "8",
    "shape5": "9"
  }
}

SECURITY​

User Action

Event Type

Category 

eventData payload

Successful Login

loginsuccess

SECURITY

Not applicable

SETTINGS​

User Action

Event Type

Category 

eventData payload

Changing a Feature Flag through the API

set-feature-flag

SETTINGS

 
"eventData": {
  "featureFlag": "DATA_RETENTION",
  "setActive": "true"
}

Reading the Feature Flag Status

get-feature-flag

SETTINGS

 
"eventData": {
  "featureFlag": "DATA_RETENTION"
}

Feature Flag set for repository

set-repository-feature-flag

SETTINGS

 
"eventData": {
  "featureFlag": "DATA_RETENTION",
  "allRepositories": false,
  "repositories": [
    {
      "repositoryId": 1,
      "repositoryName": "repo"
    }
  ]
}

*The repositories array will only be present if allRepositories is false.

**This only audits the changes in repositories for the feature flag. The feature flag being turned on/off will still be audited under set-feature-flag.

A new server setting is created

server-setting-create

SETTINGS

 
"eventData": {
  "newValue": "true",
  "setting": "igrafx.defaults.newuserlocale"
}

*Values for sensitive settings will be redacted to: ********.

A server setting is updated

server-setting-update

SETTINGS

 
"eventData": {
  "newValue": "true",
  "oldValue": "false",
  "setting": "igrafx.defaults.newuserlocale"
}

*Values for sensitive settings will be redacted to: ********.

A server setting is deleted

server-setting-delete

SETTINGS

 
"eventData": {
  "oldValue": "false",
  "setting": "igrafx.defaults.newuserlocale"
}

*Values for sensitive settings will be redacted to: ********.

ROLE_MANAGEMENT​

User Action

Event Type

Category 

eventData payload

Server role created

server-role-create

ROLE_MANAGEMENT

 
"eventData": {
  "roleId": "{roleId}",
  "roleName": "{roleName}"
}

Server role updated

server-role-update

ROLE_MANAGEMENT

 
"eventData": {
  "roleId": "{roleId}",
  "rights": [
    "ManageEndorse",
    "ManageRequiredWatchers"
  ],
  "roleName": "{roleName}"
}

*The rights will be the entire list of granted permissions at the time of the update.

Server role deleted

server-role-delete

ROLE_MANAGEMENT

 
"eventData": {
  "roleId": "{roleId}",
  "rights": [
    "ManageEndorse",
    "ManageRequiredWatchers"
  ],
  "roleName": "{roleName}"
}

*The rights will be the entire list of granted permissions at the time of deletion.

Server role assigned to User/Group

server-role-assigned

ROLE_MANAGEMENT

 
"eventData": {
  "role": {
    "roleName": "server role",
    "roleId": "4"
  },
  "userId": "3"
}

*userId can also be groupId if the server role was assigned to a group instead of a user, like in the example.

Server role removed from a User/Group

server-role-unassigned

ROLE_MANAGEMENT

 
"eventData": {
  "role": {
    "roleName": "server role",
    "roleId": "9"
  },
  "userId": "3"
}

*userId can also be groupId if the server role was assigned to a group instead of a user, like in the example.

Repository role created

repository-role-create

ROLE_MANAGEMENT

 
"eventData": {
  "roleId": "{roleId}",
  "roleName": "{roleName}"
}

Repository role updated

repository-role-update

ROLE_MANAGEMENT

 
"eventData": {
  "roleId": "{roleId}",
  "rights": [
    "ManageEndorse",
    "ManageRequiredWatchers"
  ],
  "roleName": "{roleName}"
}

*The rights will be the entire list of granted permissions at the time of the update.

Repository role deleted

repository-role-delete

ROLE_MANAGEMENT

 
"eventData": {
  "roleId": "{roleId}",
  "rights": [
    "ManageEndorse",
    "ManageRequiredWatchers"
  ],
  "roleName": "{roleName}"
}

*The rights will be the entire list of granted permissions at the time of deletion.

Repository role assigned to User/Group

repository-role-assigned

ROLE_MANAGEMENT

 
"eventData": {
  "repository": {
    "repositoryId": "1",
    "repositoryName": "Company"
  },
  "role": {
    "roleName": "repository role",
    "roleId": "4"
  },
  "userId": "7"
}

*userId can also be groupId if the repository role was assigned to a group instead of a user, like in the example.

**The repository block will NOT be present if the repository role applies to ALL repositories.

Repository role removed from a User/Group

repository-role-unassigned

ROLE_MANAGEMENT

 
"eventData": {
  "repository": {
    "repositoryId": "1",
    "repositoryName": "Company"
  },
  "role": {
    "roleName": "repository role",
    "roleId": "4"
  },
  "userId": "7"
}

*userId can also be groupId if the repository role was assigned to a group instead of a user, like in the example.

**The repository block will NOT be present if the repository role applies to ALL repositories.

Item role created

item-role-create

ROLE_MANAGEMENT

 
"eventData": {
  "roleId": "{roleId}",
  "roleName": "{roleName}"
}

Item role updated

item-role-update

ROLE_MANAGEMENT

 
"eventData": {
  "roleId": "{roleId}",
  "rights": [
    "ManageEndorse",
    "ManageRequiredWatchers"
  ],
  "roleName": "{roleName}"
}

*The rights will be the entire list of granted permissions at the time of the update.

Item role deleted

item-role-delete

ROLE_MANAGEMENT

 
"eventData": {
  "roleId": "{roleId}",
  "rights": [
    "ManageEndorse",
    "ManageRequiredWatchers"
  ],
  "roleName": "{roleName}"
}

*The rights will be the entire list of granted permissions at the time of deletion.

Item role assigned to a user or group

item-role-assigned

ROLE_MANAGEMENT

 
"eventData": {
  "role": {
    "itemId": "{itemId}",
    "roleId": "{roleId}",
    "roleName": "{roleName}",
    "repositoryId": "{repoId}"
  },
  "userId": "{userId}"
}

*userId can also be groupId if the repository role was assigned to a group instead of a user, like in the example.

Item role unassigned from a user or group

item-role-unassigned

ROLE_MANAGEMENT

 
"eventData": {
  "role": {
    "itemId": "{itemId}",
    "roleId": "{roleId}",
    "roleName": "{roleName}",
    "repositoryId": "{repoId}"
  },
  "userId": "{userId}"
}

*userId can also be groupId if the repository role was assigned to a group instead of a user, like in the example.

GROUP_MANAGEMENT​

Automated systems create some group management actions. These actions can have special principals that indicate how the action was performed (for example, the iGrafx IdentityiGrafx Identity The iGrafx identity and access management service that brokers authentication between customer identity providers and Process360 Live components. Solution or LDAP). These principals are based on the underlying technologies and may not display what you expect (for example, signing in with SAMLSAML An XML-based standard for exchanging authentication and authorization data between an identity provider and a service provider. Process360 Live supports SAML 2.0 for SSO. via the iGrafx IdentityiGrafx Identity The iGrafx identity and access management service that brokers authentication between customer identity providers and Process360 Live components. Solution may show the principal SYSTEM: OAuth2 because the underlying technology is OAuth2).

User Action

Event Type

Category 

eventData payload

A user is added to a group

group-assigned-user

GROUP_MANAGEMENT

 
"eventData": {
  "user": {
    "loginName": "{loginName}",
    "userId": "{userid}"
  },
  "group": {
    "groupName": "{groupName}",
    "groupId": "{groupId}"
  }
}

*This will not audit new users being created and added to the everybody group. As well as the initial assignment for the system administrator.

A user is removed from a group

group-unassigned-user

GROUP_MANAGEMENT

 
"eventData": {
  "user": {
    "loginName": "{loginName}",
    "userId": "{userid}"
  },
  "group": {
    "groupName": "{groupName}",
    "groupId": "{groupId}"
  }
}

A group is added to a group

group-assigned-group

GROUP_MANAGEMENT

 
"eventData": {
  "childGroup": {
    "groupName": "{groupName}",
    "groupId": "{groupId}"
  },
  "parentGroup": {
    "groupName": "{groupName}",
    "groupId": "{groupId}"
  }
}

A group is removed from a group

group-unassigned-group

GROUP_MANAGEMENT

 
"eventData": {
  "childGroup": {
    "groupName": "{groupName}",
    "groupId": "{groupId}"
  },
  "parentGroup": {
    "groupName": "{groupName}",
    "groupId": "{groupId}"
  }
}