Skip to main content
Planned

Adjust automations to not have the user named from SafetyCulture Integration Builder

Related products:Integrations
Camille
cara.beraldo
  • Camille
    Camille
  • cara.beraldo
    cara.beraldo

Ben Snyders

Within the SafetyCulture Integration Builder, if I have setup automations via an API token anything that results within platform will name the action as coming from me.

Example

This is a problem on two fronts:

  • Everyone in my org thinks I am actually creating all this stuff - so they contact me… but really it is an automated workflow that I have created based on our business requirements
  • I get all the notifications for the stuff I have created via the workflows, so if I ever have to know if something is relevant to me I have disengaged from notifications all together from SC

It would be great if we could have any automations created via the builder not name the user, but have a title that is more generic an example but not precious of “Automated workflow” - Created by automated workflow. Also don’t give me the notifications please!

 

Hope that makes sense, if you have any questions reply and can get  you more information.

5 replies

Austin Turner
SafetyCulture Crew
Forum|alt.badge.img+2
  • SafetyCulture Crew
  • 36 replies
  • March 9, 2023

Thanks for the feedback Ben.

 

One technique you might like to try is to create a dedicated user for integrations: 

  1. You can create a User with the name you would like to appear e.g. “Automated Workflow”
  2. Create a new SafetyCulture Connection in Integration Builder with that user’s API key
  3. Use the new connection in those recipes
  4. Actions will then appear as created by “Automated Workflow”
  5. Notifications can be configured separately for that user
  6. Permissions can be configured separately from your own account

Bianca.Taylor
Forum|alt.badge.img
  • Former SafetyCulture Crew
  • 553 replies
  • July 4, 2024
NewOpen

Austin Turner
SafetyCulture Crew
Forum|alt.badge.img+2
  • SafetyCulture Crew
  • 36 replies
  • July 4, 2024

Hi Ben,

We are currently designing a new API key system. Our current concept is:

  • Admins will be able to manage API keys centrally for an organisation
  • Link API key with a special Service User account rather than the User who created it
  • API keys will have extended expiry (365 days from last activity)
  • API keys will continue to operate if the user who created them is deactivated
  • Service User access/ permissions can be individually scoped to restrict data and actions available to the integration
  • Attribution of activites (creation of Actions etc) will be attributed to the Service User for that Integration (e.g Created By SuccessFactors Integration or Created By SafetyCulture Integration Builder).

I’m keen to get feedback on this if you have ideas for further improvements/ changes.


Bianca.Taylor
Forum|alt.badge.img
  • Former SafetyCulture Crew
  • 553 replies
  • July 4, 2024
OpenPlanned feature

Corey
Forum|alt.badge.img+6
  • Speaker
  • 260 replies
  • July 8, 2024

Austin, your original workaround to have a dedicated user is exactly what I have been considering.  However, central management of API keys would be helpful. Because the Integration Builder is limited as to who can use it, I will have to create integrations for other users.  Rather than asking for their key, if I could access and label keys for them, it would be much easier.  As you stated, it would also be helpful for deactivated user keys to still work until we replace the user.  I would also like to be able to create keys with specific permissions/access rather than having to create special users or get other users’ keys.  There are situations when we may need data available to all managers of a site or all users of a site, and we have to “pick” a user that meets that criteria currently to get the right key.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings