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.

Choose what gets audited​

The platform records the events this page describes only while Audit Settings is set to Audit on. For the levels, the default per channel, and the permission required, see Audit settings. On an on-premises installation, Audit on also writes every event to local log files on the application server — see File-based audit logging.

Access the audit data​

In the administration UI, Download audit data under Audit Settings exports the events for a time range and optional filters as a JSON Lines (JSONL) file — one event per line, in the format under General payload structure. For the steps, see Export audit events. The rest of this section covers the REST API.

Query the REST API​

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_PLATFORM_URL/api/auditevents

On iGrafx Cloud, YOUR_PLATFORM_URL is YOUR_SUBDOMAIN.igrafxcloud.com.

The caller needs the Access REST API and Access Support Features server permissions. On an on-premises installation, the REST API is off until an administrator turns on Enable API — see Access the REST API.

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.

Download the events as a JSON Lines file​

Added in 20.3.0, the same endpoint can return the events as a JSONL file — the format the administration UI exports — instead of a JSON array. Send the request with the header Accept: application/x-ndjson:

GET https://YOUR_PLATFORM_URL/api/auditevents
Accept: application/x-ndjson

The response is a file download named iGrafxPlatform-AuditData-<timestamp>.jsonl, with one event per line in the format under General payload structure. The query parameters and permissions are the same as above, with two differences:

  • Audit on has to be in force. At any other setting the JSONL request fails, whereas the JSON form still returns the events recorded before the setting changed.
  • secondThreshold can't exceed 30 days.

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: ********.

A repository setting is created

repository-setting-create

SETTINGS

 
"eventData": {
  "setting": "igrafx.repository.RequireCommentCheckin",
  "repository": "{repositoryName}",
  "newValue": "true"
}

*The baseline values written when a repository is installed, registered, or upgraded are not audited. The repository's internal variables — its identifier, version, timestamps, and migration markers — are never audited, whatever changes them.

A repository setting is updated

repository-setting-update

SETTINGS

 
"eventData": {
  "setting": "igrafx.repository.RequireCommentCheckin",
  "repository": "{repositoryName}",
  "newValue": "true",
  "oldValue": "false"
}

*An update that stores the value the setting already held is not audited.

A repository setting is deleted

repository-setting-delete

SETTINGS

 
"eventData": {
  "setting": "igrafx.repository.RequireCommentCheckin",
  "repository": "{repositoryName}",
  "oldValue": "true"
}

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).

Group changes that come from a synchronized LDAP directory aren't audited: when synchronization creates, renames, or removes a group to match the directory, no create-group, update-group, or delete-group event is recorded.

Every group reported in these events carries the directoryId and directoryName of the user directory it belongs to, so that groups holding the same name in different directories can be told apart.

User Action

Event Type

Category 

eventData payload

A group is created

create-group

GROUP_MANAGEMENT

 
"eventData": {
  "groupId": "{groupId}",
  "groupName": "{groupName}",
  "directoryId": "{directoryId}",
  "directoryName": "{directoryName}"
}

A group is renamed

update-group

GROUP_MANAGEMENT

 
"eventData": {
  "groupId": "{groupId}",
  "groupNameBefore": "{groupNameBefore}",
  "groupNameAfter": "{groupNameAfter}",
  "directoryId": "{directoryId}",
  "directoryName": "{directoryName}"
}

A group is deleted

delete-group

GROUP_MANAGEMENT

 
"eventData": {
  "groupId": "{groupId}",
  "groupName": "{groupName}",
  "directoryId": "{directoryId}",
  "directoryName": "{directoryName}",
  "members": [
    {
      "userId": "{userId}",
      "loginName": "{loginName}"
    }
  ]
}

*members holds the users that belonged to the group at the moment it was deleted, and is empty for a group that had none.

*Deleting a user directory removes every group in it, and raises one delete-group event per group removed. Deleting a synchronized LDAP directory is the exception: its groups are removed without any events.

A user is added to a group

group-assigned-user

GROUP_MANAGEMENT

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

*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}",
    "directoryId": "{directoryId}",
    "directoryName": "{directoryName}"
  }
}

A group is added to a group

group-assigned-group

GROUP_MANAGEMENT

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

A group is removed from a group

group-unassigned-group

GROUP_MANAGEMENT

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