Hi ​@siddharam_goranale91 
 

Thank you for reaching out with your questions about storing your custom app's configuration data within the app settings in Front. I’d be happy to provide guidance on this.

Unfortunately, Front does not currently provide a built-in mechanism to store custom configuration data directly within the app settings. However, there are some potential workarounds depending on your requirements:

1. Leverage Custom Fields

• You can use custom fields to store configuration data. While custom fields are typically designed for storing structured information related to conversations or contacts, you could repurpose them to hold configuration details by encoding the data (e.g., JSON as a string).
• Considerations:
  • Ensure the custom field is appropriately scoped (e.g., conversation or contact level) based on how the data will be used.
  • There is a character limit for custom fields, so you may need to limit the size of your configuration data.

2. External Storage

• If your configuration data is complex or exceeds the limitations of custom fields, you could consider managing it externally:
  • Store the configuration in your own database and fetch it via an API call when needed.
  • Use a unique identifier (e.g., team ID or app instance ID) to map the configuration data to the corresponding Front workspace or app instance.
• Benefits:
  • More flexibility and control over data storage.
  • Avoids limitations related to Front's internal storage mechanisms.

While Front’s current API and app framework do not provide direct support for storing custom configuration data, the workarounds above can help you achieve similar functionality.

Best, 
Justin

Hi ​@justin 
We want to store a unique integration token and need it to be accessible for every conversation. Considering that custom fields have fixed types, how can we initially store this token and ensure it is consistently available across all conversations? Additionally, we would appreciate guidance on how to retrieve the same token for each conversation.

Hi ​@siddharam_goranale91!

I’m stepping in while Justin is out on holiday.  I’ll also need to close the duplicate request you made here:

It’s ill-advised to take the first route of using custom fields.  There are no means to bulk update custom fields.  The requirements here will be:

• Updating all historical conversations by Front’s API to set the custom field with the token.  You will be subject to API rate-limits and this may not be feasible depending on the number of conversations.
• Creating a rule that sets the custom field on all new messages.  You would need to have Company Rules enabled on your account to set this for individual and shared inbox messages.

By far, the second approach is recommended, otherwise you’ll need to do the above.  Also, it’s generally risky to store any token in a place that’s visible to your entire team.

Retrieving the token is highly dependent on how you want to use it.  Do you have a Front plugin or integration that you’re trying to use it with?

Hi ​@evano 
Thank you for your clarification regarding app settings and your recommendation to use custom fields for storing configuration data.

To provide more context, we have developed a custom plugin for Front that provides insights within the plugin interface. Currently, the plugin is distributed as a private build, but we plan to publish it on the Front App Store soon.

At present, we include the token in a hosted URL in the following format:
http://localhost:4200/?isFrontApp=true&token=#SW#85753JS4Y73222384.

We are exploring a more efficient and secure method to handle the token, which varies per Front instance. Based on your suggestion, we are considering storing the token in custom fields. This would allow the plugin to dynamically retrieve the token and use it for API calls, ensuring the correct integration data is returned for each Front instance.

However, I’m not entirely clear on your suggested approach,
Your insights and any additional recommendations would be greatly appreciated as we move forward with implementing this solution.

We previously built TheLoops app for Zendesk, and we’re sharing the recording for your reference. Now, we need to create a similar app that works on Front. In Zendesk, there are settings that allow securely saving and accessing unique identification information for a specific instance. This enables our backend server to identify the tenant/customer for whom the request is triggered and provide the relevant insights.

However, we haven’t yet identified whether Front offers a similar capability. Another possible approach is to require users to log in to our app first, allowing us to determine the associated tenant and deliver the correct insights. This method is already used by the Salesforce Front app.

The challenge with this approach is that users are already logged into their Front instance, and asking them to log in again to another app is not ideal. We’re seeking your guidance on how to implement this functionality.

This is a top priority, as several of our Front customers are waiting to use our app on their Front instances. We look forward to your response!
Recording link of TheLoops Zendesk app

Hi ​@siddharam_goranale91 

Thanks for the additional details! Since you’re building a plugin, here’s a recommended approach:
 

Token Storage
 

You can use browser APIs like LocalStorage or Cookies to store the integration token securely.

• LocalStorage: Persistent and accessible only within your app's domain.

  localStorage.setItem("integrationToken", "your-unique-token"); const token = localStorage.getItem("integrationToken");

• Cookies: Useful if you need the token sent with backend API requests. 

Dynamic Retrieval
 

I realize that you want to avoid login within Front but this is the best way forward that I see through the plugin. Implement a login flow during plugin setup:

1. Prompt users to log in, authenticate, and fetch the tenant-specific token.
2. Store the token locally for seamless API use.

This ensures tenant-specific insights while avoiding Front's limitations on storing sensitive data. Additionally, this login should persist and the user would only need to login once to your app, given their data caches are not cleared. 
 

Best,
Justin