Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Custom Fields] Tags #1029

Closed
jstanden opened this issue Oct 31, 2019 · 5 comments
Closed

[Custom Fields] Tags #1029

jstanden opened this issue Oct 31, 2019 · 5 comments

Comments

@jstanden
Copy link
Owner

@jstanden jstanden commented Oct 31, 2019

Implement a new type of custom field for tagging. This would work like 'multi-checkbox' or 'list', but the set of possible options is unbounded and not fully displayed. It would accept comma-delimited tags, autocomplete tags as you type, and allow you to create new tags by simply typing a new one that doesn't exist yet.

@jstanden jstanden added this to the 9.4 milestone Oct 31, 2019
@jstanden jstanden added this to To do in 9.4 via automation Oct 31, 2019
@beatbesmer

This comment has been minimized.

Copy link

@beatbesmer beatbesmer commented Oct 31, 2019

I guess the 'can create new tags' permission will be granted as usual by role to specific Workers?

@mryanb

This comment has been minimized.

Copy link

@mryanb mryanb commented Oct 31, 2019

@beatbesmer That would be great to prevent some users from potentially duplicating tags.

@jstanden

This comment has been minimized.

Copy link
Owner Author

@jstanden jstanden commented Oct 31, 2019

@beatbesmer It might be complex to itemize custom fields privs within roles, just because there could be 100s of custom fields (owned by app, bots, groups) and dozens of roles. But I'm all for the same principle of roles in governing who can add new options to custom fields.

It's easy to imagine scenarios where such a field should mandate uniformity (like a picklist) from a pre-defined set of options. For instance, world countries or U.S. states. You wouldn't want workers creating variations like U.S., us, USA, United States, and United States of America. There's a lot of overlap between the needs of a field like that (more options than you want to display on the screen at once) and tagging.

My first instinct would be extending those option-picker style custom fields with an additional property, like roles, of a worker query that defines who can add options.

The natural (and more performant) extension of that would be specifying the roles that are able to add options from the custom field config. That's easier to manage, since from any given custom field (out of hundreds) there's likely a smaller set of roles to consider. Additionally, the roster of those roles is already cached for quick lookups, which we'd need in record validation fairly often.

Perhaps that's already what you meant. I think that concept would work really well.

This should be quick to explore, since custom fields have been extension-based for a few major versions. I'll see if we can get this into 9.4, since workflows like this come up a lot.

@jstanden

This comment has been minimized.

Copy link
Owner Author

@jstanden jstanden commented Oct 31, 2019

Also to add some further thought it is nice to be able to organize the
tags like "Priority::High, Priority::Low or Integration::Salesforce
Integration::Hubspot" so we could query for records that have a priority
tag and Salesforce.

Yeah, that would be great.

It's also something I need for machine learning workflows. We have clients who use (or want to use) external classifiers (e.g. AWS Comprehend) on new messages to find statistically interesting phrases, entity extraction, language/dialect detection, etc.

That's easy enough to do on the prediction side with a combo of behaviors + custom fields.

However, training those models requires a lot of tagged data. And not only do you need to tag a product name on the client's message, but you need to highlight the phrase in the message that led to the tag, so it can better learn to extract those things (e.g. by surrounding parts of speech).

That would be easier if tags themselves were records, and the custom field had some way of partitioning them within its purview (e.g. by custom fields that categorize the tags). You could also then directly link the tags to other records, add custom fields to them (like the classification phrases/ranges), share them between fields.

That also assists with machine learning, because you could compare tags linked to a new message with the same tags on KB articles, problem/solutions, FAQs, snippets, etc. That ties into what you said above, where something tagged with a particular product and particular component/problem/question could more easily find related resources by intersecting all of those things.

That's also potentially a way to solve the "linked custom picklists" feature requests -- something like make/model in car, where model options depends on make. Models "tags" (options) would have a 'make' custom field on them. The suggestions in the 'Model' field could depend not only on the fact they have a 'Make' field set, but on the current editor value of that 'Make' field.

It's not difficult to hardcode things like that (Group/Bucket), but there isn't an easy way to do the same thing from custom fields.

So perhaps this whole idea of "tags" could be expanded as "custom field options", where options aren't limited to a static list of values directly in the custom field config. They could be dynamic, from option records, or even external data like API requests (in the case of fields like make/model, or ZIP codes). When automations are released, it would be easy to add one to a 'dynamic picklist' type field for determining how to suggest options.

That does feel like two new, similar but distinct, custom field types: tags (with tag records, storing those IDs, and having room for meta on tags), and dynamic picklists (which could optionally use a custom record, or static list, but could also use external data sources for tag suggestions). With automations on a dynamic picklist, that could also consider the other fields currently set, or in the process of being set, on a record editor (group/bucket, make/model).

@jstanden jstanden moved this from To do to In progress in 9.4 Oct 31, 2019
@jstanden

This comment has been minimized.

Copy link
Owner Author

@jstanden jstanden commented Nov 2, 2019

This is possible in 9.4-dev now with the implementation of 'Record links' (plural) custom fields. We previously only had a 'Record link' (singular).

You can create a new custom record for 'Tags' (or industries, countries, states, categories, etc). That also allows you to determine owners for tags, configure their ACL in roles, add custom fields to them, link them (e.g. to kb articles and snippets), etc.

Add a 'Record Links' custom field to the record you want to tag (e.g. tickets, orgs, opps), and set its type to 'Tag' (your custom record).

That record will now provide a multi-chooser for selecting tags. New tags can be added by workers with access (based on the role and custom record type).

That should be flexible enough to share 'tags' between record types when desirable, or using separate record types otherwise (industries vs tags).

We'll also add a 'required query' option for the custom field's chooser and autocomplete, so you can partition the linked records by properties, fieldset, names, or anything else.

@jstanden jstanden closed this Nov 2, 2019
9.4 automation moved this from In progress to Done Nov 2, 2019
jstanden added a commit that referenced this issue Dec 10, 2019
…eld type.

We previously only had a 'Record link' (singular).

You can create a new custom record for 'Tags' (or industries, countries, states, categories, etc). That also allows you to determine owners for tags, configure their ACL in roles, add custom fields to them, link them (e.g. to kb articles and snippets), etc.

Add a 'Record Links' custom field to the record you want to tag (e.g. tickets, orgs, opps), and set its type to 'Tag' (your custom record).

That record will now provide a multi-chooser for selecting tags. New tags can be added by workers with access (based on the role and custom record type).

That should be flexible enough to share 'tags' between record types when desirable, or using separate record types otherwise (industries vs tags).

We'll also add a 'required query' option for the custom field's chooser and autocomplete, so you can partition the linked records by properties, fieldset, names, or anything else.

Fixes #1029
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
9.4
  
Done
3 participants
You can’t perform that action at this time.