SYS_USER_GROUPS question

I have a followup/related question. I would like to enter an assigned group as a honeycode contact field in a record when I have a button click event automation triggered. (it's not a group that the logged in user is part of, so I can't get that from SYS_USER_GROUPS). For example I would like to record an AWS SSO Group, "HC-VendorSetupTeam", in a contacts-formatted field as a contact. I have been able to assign this to the field as a string in an automation like ="HC-VendorSetupTeam", but the record in my table stores it as a string value rather than as a contact type. I'm assuming there is a built-in table that contains these sso user/group items, but I don't know what the table is named. For example, I should be able to do something like this: "=FINDROW(Contacts,"Contacts[Name]=%","HC-VendorSetupTeam")" with the contact table. How can I go about doing this?

I've also on occasion gotten results identified as "beehive" by accident but currently cannot duplicate. Is there any documentation on that object/table?

Thanks in advance :honeybee: :honey_pot: crew! AWS :cloud: FTW!

Hi @Matt-1edd, thanks for your question! :slight_smile: :honeybee:

The $[SYS_USER] and $[SYS_USER_GROUPS] variables refer to the contact or group of the user currently using an app. This means that you can use the variables within an app, however they would not be used in Tables. You can find more info in this article (on the bottom of the article, it specifies where the variables can be used in automations as well): Variables in Honeycode

Just so we have more information, could you elaborate on why you'd like to make the SSO group a contact? What are your goals around this?

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 :slight_smile: compared to writing a bunch of javascript, and I don't need additional devs to build and manage an equivalent solution.

888e8218b10d6f5d6b0ffbf12dde58f4f3d91399

Moderator note: Edited out personal information in image.

Thank you for letting us know what you’re looking to do, @Matt-1edd :honeybee:

As of today, Honeycode does not support programmatically updating contacts or groups in Honeycode. The management of contacts would be done on the Teams page (for non-SSO) or as outlined in this guide for SSO (such as your case): Single Sign-On (SSO) for Honeycode - Amazon Honeycode

Specifically to your asks, I’ll note that contact data would not be managed in a Honeycode table or app.

In regards to APIs, here’s a resource you can explore to see what actions are available with API calls: Welcome - Amazon Honeycode

You bring up a lot of great ideas to bring to our team; I’m happy to pass all of this along for an evaluation as feature and improvement requests for Honeycode. We’re also interested in speaking with you further as we continue developing. Please keep an eye out for a message from our team to learn more about your use case. :slightly_smiling_face: :honey_pot:

1 Like