For configuring provisioning , you will need access to Platform configuration console.

1. Open the Administration area (a gear symbol).
2. Open Connectors view.
3. Choose "New connector" 

4. Select Data Source type to be Generic REST API

5. Give name for the connector and add connection settings:

• Connector name - give your connector a friendly name (name can be changed afterwards)
• Host url - base url for REST API. This can be used as prefix for final url to be called.
• REST Connector type - select Generic
• Authentication method - Select Dynamic Token

• Login url: https://login.microsoftonline.com/2b6a6dc0-a6f1-47ff-8818-bafda12d454c/oauth2/v2.0/token
• Login body(change your client_id and client_secret, other two attributes have constant values): client_id=123abc&client_secret=abcde&grant_type=client_credentials&scope=499b84ac-1321-427f-aa17-267ca6975798/.default
• Login Method: POST
• Login Content Type: application/x-www-form-urlencoded
• Login token valid for (in seconds): 3598
• Login headers: Content-Type = application/x-www-form-urlencoded
• Token usage: Bearer @TOKEN@
• Token attribute in response: access_token

6. Set correct pagination if you are going to use this connection with Scheduled tasks

7. Fulfill WebAPI user information

• WebAPI user - select correct WebAPI user which is used when writing data from external system to Matrix42 Core, Pro and IGA solutions
• WebAPI password - password for the WebAPI user

8. Save connector information

9. Add external Microsoft Azure DevOps root https certificate to be trusted by Connector management (EPE). This can be done only by Matrix42: Add certificate.

10. Matrix42 Core, Pro and IGA solution is now able to connect to Microsoft Azure DevOps

• Next step is to configure scheduled task for data read or event task for data writing and actions towards Microsoft Azure DevOps.

Reading data from Microsoft Azure DevOps with Scheduled tasks is not supported at the moment. Reason for this is that Microsoft Azure DevOps uses pagination method which is not supported by our Generic REST API connector. In Azure DevOps response header contains x-ms-continuationtoken for pagination.

But you can still read one object from Azure DevOps by using Event-based tasks and Workflow Orhestration Node with Action GET.

Here is basic example of Event task and Orchestration node, which are used to create tickets to Microsoft Azure DevOps. 

1. Add Event-based task under correct Connector, by clicking “New Task”

2. Set attributes to task

Task name - descriptive unique name
Task usage - Event
Mappings type - Generic Template
Query - url for the API you want to call. In this example we create ticket, so we are using query: You can this empty. We will in this example set api url to Orchestration node REST URL attribute.

Query headers: set these three headers as seen on screenshot.
Accept / application/json
X-TFS-FedAuthRedirect / Suppress
Content-Type / application/json-patch+json

Date Attribute formatter - set correct format if you are provisioning date attributes: yyyy-MM-dd
DateTime Attribute formatter - set correct format if you are provisioning datetime attributes: yyyy-MM-ddTHH:mm:ssZ

Set Generic Mappings

Target template - template from which Workflow you are going to call this task
Target folder - folder for your data

No not set attributes to mapping table (external attribute - local attribute). Attribute mapping is done on workflow orchestration node.

3. Save task

4. Create Orchestration node to your workflow, to call this event-based task

Orchestrate - Provisioning Engine
Data Source - Generic REST API
Activity - Generic REST call
Target - Create ADO ticket (your event-based task name)
Action - In this example POST as we are creating tickets
REST URL - in this example /$Bug?api-version=7.1 as we are creating tickets with type Bug you can change that Bug to be something else supported by Azure DevOps to create different type of tickets.
REST Body - you can generate API call body directly here. Or in more complicated cases generate it separately (in script node) to some attribute, and then us that attribute here. In this case body to create ticket is created directly here. 
Body what we use in this example has Title and ReproSteps values read from datacards subject and details attributes. Hard coded Effort for 3.0. Tag MyTESTTag and AreaPath hardcoded to Test\\My team1. Actual areaPath has only one \ but this need to have double \\ to be json compatible.
[
 { "op": "add", "path": "/fields/System.Title", "value": "$subject$" },
 { "op": "add", "path": "/fields/Microsoft.VSTS.TCM.ReproSteps", "value": "$details$" },
 { "op": "add", "path": "/fields/Microsoft.VSTS.Scheduling.Effort", "value": 3.0 },
 { "op": "add", "path": "/fields/System.Tags", "value": "MyTESTTag" },
{ "op": "add", "path": "/fields/System.AreaPath", "value": "Test\\My team1" }
]

REST Response attribute - response of API call will be stored to this attribute
Provisioning exception - if there is issue with API call, exception will be stored to this attribute

Finalize your workflow other nodes and flow

Save workflow and Publish it

5. Test Workflow and Event-based task

This example workflow creates one bug ticket and adds one sub-task for it

Add ADO ticket

Get ADO ticket number

Add ADO sub task

utilizes the created bug ticket number, which we stored to attribute on “get ADO ticket number” -node

Restrictions in 2025.3

More than 1 level of subqueries for scheduled tasks are not supported, for performance reasons.

Scheduled tasks for reading mass amounts of data from Microsoft Azure DevOps are not supported as Microsoft Azure DevOps uses pagination method which is not supported by our Generic REST API connector.