There are multiple ways to assign a value to a field in assignment rules. Some of the most common are to assign a fixed value (e.g., a text string, a field from an available data view, a date, or with additional mathematical functions).

This document will show all of these common assignment methods.

The API call remains the same for all methods, the differences are in what entity fields are used in the body of the API call.

This call is a POST call with the header of

http://99.99.99.99:8080/core/1.0/API/assignmentRule.

In Postman, the API looks like this:

The body of the file for this call will look like this:

{
    "context": {
        "user": "id_name",
        "password": "password",
        "project": {
            "name": "imp_payments_demo",
            "version": "1.0"
        },
        "workSet": {
            "name": "api_2_workset",
            "version": "1.1"
        }
    },
    "entity": {
        "step": {
            "name": "imp_enter_details",
            "version": "1.0"
        },
        "attribute": "test_string",    
        "operands": [
            {
                "operator": "ASSIGN",
                "value": "125"
            }      
        ]
    }
}

In the entity section, you will need to provide the step name and version (version can be validated in the ‘data blocks’ section of TDO or on the ‘assembled data’ page).

The attribute name is the name from the list in the TDO data assignment page. In this case, we are working on the third attribute in the list:

In the final section of the body, we are specifying the method being used (‘ASSIGN’) and the value to be assigned (‘125’). Since we have not specified a format type, this will be assigned using the default value of STRING.

When the API is successfully run, you will receive the following return message:

Note that the return message starts with the Mongo object ID, provides the rule name and properties.

Here is that rule in TDO after the API is run.

You can see that the rule name on the TDO screen is the same as the rule name returned to Postman after the API was run and the value assigned is the value sent in the API.

These calls can be used to create, update, get all, get details, delete assignment rules. The URL’s and call types are listed in the table below.

For the create and update API’s, the body fields are needed to provide the necessary context. A list of these fields and which call they are required for is provided below.

When you want to assign a value using the FORMAT function (e.g., assign the current date to a date field in a specific format) you need to add the ‘function’ parameter to the ‘operand’ section of the message, and then the actual formatting string in the ‘value’ section.

The return message will include the information on the rule that you created.

In TDO, you can now see the rule that you created.

This call gets the details for all assignment rules in a workset. It is sent as a POST call.

The body of the call contains the information on the project and workset you want to get assignment rule information on.

The return message will contain information on all rules in that workset. In the sample below, there are two steps in the workset and rules for both steps are returned.

For the remaining calls referenced in this section, the rule ID returned in this call is used to target the call to a specific rule.

This call is used to change an assignment rule. The existing assignment rule for this field is a simple assignment from the customer view.

We will change the field being assigned, and add a condition to the rule.

This call is sent as a PATCH call.

The body of the call contains the information being sent to update the rule. The project and workset are sent to set the context. The entity is sent using the rule ID from the Get Assignment Rules call (67ea97d49df32c722419d903) to point to the specific rule being updated. Finally, the call contains the operand and conditions to be sent (using the same format as when creating a rule with operands and conditions).

The return message contains the information on the updated rule.

This call returns the details on a specific rule. The URL includes the object ID for the rule being called and again is sent as a POST call.

The body of the message contains the project name and workset name that the specific rule is in.

The results message will include the rule details.

When using conditions in assignment rules, you will need to send each condition in a separate API call. This is because each condition is creating a different rule, and only one rule can be sent per API.

In this example, we are using the account currency (GBP or USD) to set the value for a numerical field (test_number). In the first call, our body will look like this:

Here, we are setting the condition that if the ‘currency_a’ field is equal to ‘GBP’ then the field should be set to ‘100’. For the second rule, below, we are setting the condition to ‘if currency_a equals USD then test_number is 500’.

The return messages are the same as for the other assignment rule calls. In TDO, after running both of these calls, the assignment rules page now reflects this. Each rule is shown individually on the page and sets the value per the rule only if the condition is equal to what was stated.

Sometimes you may need to perform operations in assignment rules that use operators such as ‘Add’, ‘Subtract’, etc. (Note that ‘Add’ is both a mathematical operator – add the values of two fields together – and also a text concatenation operator – add one string to the end of another string.)

To perform these operations, you send the multiple operators in a single ‘operands’ array, as shown below where we are assigning the value from the ‘balance’ field in the acts_view to ‘test_number’, and then subtracting 525 from that value.

When run in TDO, the response message for a successful call will look very similar to other rules assignment messages. Both of the operators and their values will be reflected in the return message.

In TDO, after this call runs, you will see the rule assigned to the field.

The API call remains the same. The body varies only in the ‘entity’ section. In the straight text assignment above, the ‘value’ section contains only the string to be assigned. Here, in the ‘value’ section, we include three additional items from the data view to be used as the data source: the data view name, it’s version, and the name of the attribute from the data view to be used.

{
    "context": {
        "user": "usef_id",
        "password": "xxxx",
        "project": {
            "name": "imp_payments_demo",
            "version": "1.0"
        },
        "workSet": {
            "name": "api_2_workset",
            "version": "1.1"
        }
    },
    "entity": {
        "step": {
            "name": "imp_validate_outcomes",
            "version": "1.0"
        },
        "attribute": "test_string",
        "operands": [
            {
                "operator": "ASSIGN",
                "value": {
                    "name": "cust_data_view",
                    "version": "1.0",
                    "attribute": "customer_type"
                }
            }
        ]
    }
}

In Postman, the call looks like this:

The return message (for a successful call) is the same as for the prior call, showing all of the details for the rule created:

In TDO, you can see the new rule.

This call is used to delete an assignment rule. Care should be taken when using this call, as there will be no prompt (‘are you sure you want to delete this rule?’) when it is sent. The deletion request will be immediately processed.

It is sent as a DELETE call, and the url includes the ID (from the ‘get assignment rules’ call) for the rule to be deleted.

The body of this call is the same as the body for ‘Get Assignment Rules’ or ‘Get Rule Details’ call, containing the user credentials, project, and workset information.

{
    "context": {
        "user": "user_ID",
        "password": "xxxx",
        "project": {
            "name": "imp_payments_demo",
            "version": "1.0"
        },
        "workSet": {
            "name": "api_2_workset",
            "version": "1.1"
        }
    }
}

The return message for this call is very simple, with a single return code (‘1’ for ‘true’).

In TDO, we can now see no rules for this field (this is the same rule that was updated using the ‘Update Assignment Rule’ call in the previous section).