Job title is not set

[zubairov]

Job title on the person is not set in the Pipedrive

[hasenbanck]

The job title is not in the standard entity definition. Could it be that you added the Job Title as a custom field?

[AlpBilgin]

Pipedrive API isn't very user friendly in this case. A generalised solution could be complicated. Would this be a reason for simply letting users customise the Pipedrive component according to their needs?

[zubairov]

That could be a good solution, however we need to think how we could give at least an experienced user a possibility to alter the mapping so that we could add new fields. Standard solution for that would be dynamic metadata, however we could simply add a new optional field to the component action that would use JSONataView and if some JSONata expression will be specified there we should evaluate it and merge with the incoming message.

Example

From Pipedrive API I know that my 'Person' object has a custom field Job Title which is described as here:

so if Pipedrive component would POST a JSON Object with field c1d52d051ba03888f84b63adabbea2698db493d1 then it will be stored under Job Title in my Person. So with new JSONata extension field I could just use it to create a JSONata expression like:

{
   "c1d52d051ba03888f84b63adabbea2698db493d1": $.position
}

and it will be evaluated and result will be merged with other standard fields.

What do you think about it?

[AlpBilgin]

This is a good solution as it serves an immediate need with little development effort. I will implement it in near future for training purposes. Still, I would classify this solution under "Users customise the Pipedrive component according to their needs". This is simply a special case where Elastic.IO sales process is the user who needs customisation.

Some fields emit additional objects with derived keys (see below). If a user needs such a field they would either have to contort some code after the component or modify the component itself.

Or maybe this line of thought should go under a new issue?

{
            "id": 9075,
            "key": "15a7f48c44353dd1a4c2cfe58ec282332d945ff8",
            "name": "15",
            "order_nr": 37,
            "field_type": "daterange",
            "add_time": "2017-09-12 13:23:18",
            "update_time": "2017-09-12 13:23:18",
            "active_flag": true,
            "edit_flag": true,
            "index_visible_flag": true,
            "details_visible_flag": true,
            "add_visible_flag": true,
            "important_flag": false,
            "bulk_edit_allowed": true,
            "searchable_flag": false,
            "mandatory_flag": false
        },
        {
            "id": null,
            "key": "15a7f48c44353dd1a4c2cfe58ec282332d945ff8_until",
            "name": "End date of 15",
            "field_type": "date",
            "edit_flag": true,
            "active_flag": true,
            "is_subfield": true,
            "mandatory_flag": false
        }

[AlpBilgin]

Hello @zubairov ,

I had time today to sit down and put together an initial draft. Could you check #6 for validity?

[AlpBilgin]

It seems the platform is not really ready for #6.

I can either switch to dynamic metadata, or add a fully static 'job title' field. Which is preferable?

[zubairov]

Yes, given implementation suggestion of the custom fields may not be usable now. Suggestion would be to do following:

• [ ] Remove custom fields from incoming metadata
• [ ] Create a new enhancement request to add custom fields support to the component
• [ ] Add a note in the README.md mentioning this limitation

@AlpBilgin would be able to modify the PR?

[zubairov]

Closed as Obsolete