Hi Alyssa,
I'd like to be able to use the built in contact type as a way of assigning tasks from groups to specific users:
group <-> user
user <-> user
group <-> group
I could be just misunderstanding the platform, but I can programmatically add the logged in user as a contact type to a record by assigning it using $[SYS_USER]
in an automation. It seems that honeycode's internals are built around the contact type which is consumed/created from AWS SSO users and groups.
As examples, I can send an email to a contact type in an automation. I can also manually add a contact into a field from "table view". The drop down arrow allows me to select either a user or a group (which are both a contact type I believe). Since I can do this task manually (any user or group), and I can do it programmatically (at least the logged in user), it seems I should be able to automate storing contacts as well. Even though honeycode allows different types of data to be stored in a column, I'd prefer not to do that (ie mix contacts with strings).
Also, I plan to use the honeycode apis through lambda functions to consume data from honeycode (though I have not looked into it as yet). If there is additional detail the api provides for a contact type (properties of name, email address, or the user id guid AWS assigns to each sso user), I would like to be able to consume that directly from honeycode api.
Also, if somebody goes in to the table/spreadsheet directly to change an email address already stored as a string to another user's email address, it is possible they fat finger the incorrect string for the email address. If it's stored as a contact type the interface seems more forgiving when selecting a different contact.
Another thing I would like to do is use the group contact type in order to generate reports of what users belong to each group, so the report of group membership is directly available to users in honeycode from a list object on a honeycode screen as part of a workbook. If I can programmatically query the groups as a contact type, I could then find which users belong to each group.
Lastly, if I create new sso groups in AWS, if I store groups/users as strings, I will have to go into honeycode and create the group in there as well if I'm using some sort of lookup table/spreadsheet.
Plus for AWS benefit, if I'm attaching identities directly to contacts, instead of using strings to store my identities, AWS Honeycode gets a license fee for each of those users. Without going into details, if I'm using strings for identities I can get around having a lot of user licenses in my scenario. But it would be a lot easier for me not to have to do that. And that's what I'm starting love about honeycode, its not complicated compared to writing a bunch of javascript, and I don't need additional devs to build and manage an equivalent solution.
Moderator note: Edited out personal information in image.