What are some examples of customers having success with dynamic objects and how are they being used? 

How do dynamic objects compare to traditional sidebar plugins?

What’s the best way to learn whether or not dynamic objects will be a good fit for my organization?

Any plans for dynamic objects that update on view? Some use cases are excluded/limited where data need to be “live”, for example order status (open, packed, shipped) and shipment status (in transport, delayed, delivered). 

We’re seeing a lot of customer success with dynamic objects. Here’s a few examples 

• We've seen logistics companies use dynamic objects to detect inbound messages from fraudulent carriers and quarantine those messages with rules. This can prevent freight loads with over $200k in merchandise from being compromised by bad actors. 
• A travel agency uses dynamic objects to track guest bookings. They even use rules to flag booking conversations where the travel date is within 90 days from today. 
• We’ve seen numerous customers build dynamic objects for Order data stored in Salesforce, Shopify, in-house order tracking systems, and other tools.

And the list keeps growing 

Although similar, we believe dynamic objects offer a number advantages that make them the preferred choice for integrating third-party information into Front. 

1. Dynamic objects are no-code, meaning you can configure them entirely in Front without having to code a custom solution from scratch. This significantly lowers the barrier to setting up an application that connects critical third-party tools to Front. 
2. Dynamic objects are easier to integrate with other mission-critical Front features. The best example of this is rules: users can easily configure rules that can act on a conversation based on the information contained within a dynamic object. In the future, we plan to more closely couple dynamic objects with additional features like Front chat, analytics, contacts, and more. 
3. Dynamic objects provide context in-line, with a single click. Although plugins offer a similar convenience, nothing can beat having that information available, right in the message you’re viewing.

Here’s the exact guidance we give our go-to-market teams to evaluate wether a customer would benefit from dynamic objects 

Do your Front communications often rely on some kind of “business object”, such as an order, reservation, quote, contract, shipment, etc? 

If the answer is yes, you should absolutely explore dynamic objects.

Additional questions:

• Do you often access business objects in a separate, third-party application?
• Are these business objects identified by a common pattern, such as an ID or a unique URL?
• Does your third-party application provide an API to access information about your business objects?

If you answered yes to any of the above questions, dynamic objects will almost certainly benefit your organization. Time to learn more! 

Great question @pstos -- 

We absolutely want to ensure that dynamic objects are up to date with their source system. Without this, customers may not be able to rely on them in Front. The use cases you mentioned are perfect examples. 

By January, we plan to release an API endpoint that will allow customers to update their Front dynamic objects, externally. It will require some development effort, but we believe it is the most reliable way to empower users to keep their objects up to date. 

We’ve explored concepts like a “refresh button” in the UI that allows users to update dynamic objects on view. This is an interesting idea that would definitely provide value, but were concerned about some of the problems it may create. For example, if a customer configures a rule for a dynamic object, a user could trigger that rule simply by viewing an object in the UI. We’re not convinced this is the proper user experience. 

Regardless, we plan to actively consider new ways to solve this problem! Appreciate the input. 

Thanks for the update @robby_p. Out of curiosity; why can’t dynamic objects present in a conversation be updated when the conversation is selected by a user? Is the concern the number of refresh calls?

Would it be possible to combine the two, so that a link in the dynamic object opens the plugin panel with a custom plugin showing more detailed info? 

Thanks for the update @robby_p. Out of curiosity; why can’t dynamic objects present in a conversation be updated when the conversation is selected by a user? Is the concern the number of refresh calls?

@pstos we have some ideas for how to control the number of refresh calls. Our main concern is finding a way to keep these up to date without requiring manual user interaction. We’re looking for a way to keep objects up to date in an automated way, so that accurate objects don’t require human intervention.

Would it be possible to combine the two, so that a link in the dynamic object opens the plugin panel with a custom plugin showing more detailed info?

Absolutely. This is not possible today, but we’re definitely interested in exploring ways to more seamlessly transition between dynamic objects and the plugin panel. 

I’ve noticed that in the demo videos, the dynamic objects links are highlighted with different emojis. I haven’t seen anywhere to add this when I’ve been testing dynamic objects for my company, and the links that appear on my end just look like a normal link with . How can I add different emojis to a dynamic object link?

@kerstin great q - you can add an “app icon” in your developer application. This icon will be used in the conversation view when dynamic objects are generated.

Hi Robby, any updates on progress for this one? I’ve got dynamic objects configured but need auto refresh before I can activate for our users! :)

Hey @pstos 

While we still don’t have a completely streamlined method for refreshing application object (formerly known as dynamic object) data, we do have a few workarounds now:

• Teammates can manually type the object reference (ORDER-1234, etc.) in a comment, which will retrigger the application object data fetch.
• You can create a rule that runs on conditions of your choice (new inbound message, conversation reopened, etc.) and utilizes a dynamic variable that accesses the application/dynamic objects in a conversation to refresh all their data.
• You can use the Create link API endpoint to programmatically update app object references, so you could listen for changes to the external record and then send those updates immediately to Front.

I added some docs that discuss this in more detail. Take a look and let me know what you think.

The team is still considering whether there should be a more fully-fledged method for refreshing app object data. If you have any feedback or suggestions based on your use case, we’d love to hear them.

Thanks, that will work in this case. :)

On a related note; it would be helpful if the object was made wider. At the moment each data value field is only about 120px wide, which means that information is cut off more often than not. I see no reason why the object couldn’t have dynamic width like normal messages?

I’ll pass this feedback along to the team :)

I created an application object that looks for an 11-digit number and, in turn, connects with an API. This connector and application object is working great. I am successfully parsing out that number, getting a response, and mapping out values in the application object. At present, this connector is running in all workspaces and all inboxes. I need to have this connector run in a specific inbox, not all of them. How do I do this?

@aallmond You’ll have to edit the rule that runs your application object so that it only applies to the specific inboxes you want. Your current rule might be auto-generated and called “Create dynamic objects” (legacy name) fyi, or you might have created it yourself if you set this up more recently. Either way, you’ll want to have a rule that is at the workspace level rather than the company level and have it run only in the inboxes you desire. You can also choose to add some application objects via the rule or all of them, whatever suits your needs.