My company currently uses Front to sort messaging and work flow on the front end but we’re looking to potentially leverage more of the functionality moving forward. I’ve been looking to at least utilize Dynamic Objects to make linking our incoming messages to our TMS tickets but am also looking at setting up an API integration to utilize read/write functionality from Front, similar to a couple of the examples in the “flow-and-tell” section. I’m curious if anyone has any insight into some variables that helped you decide that it was worth it to go beyond the basic Dynamic Objects and create a full blown integration.
For example did you wait until a certain percentage of your total company as using front?
Did you wait until you had enough data about how much more efficient Dynamic Objects made your teammates’ workflow?
How much time did it take you to set up the full integration along with how many different commands with your TMS or similar software are you utilizing?
When to use Dynamic Objects for linking vs Setting up full API
+9
+2Hey
In general, I would recommend getting as much value as possible from Dynamic Objects before considering a plugin.
To your point, one of the main benefits of dynamic objects is that they work out of the box with mission-critical Front features like automated workflows. This will only become more true over time, as we’ll continue to evaluate ways to integrate dynamic objects with features like analytics, live chat, and more. So, our perspective is that dynamic objects will ultimately provide users with the most long-term value.
I’d be curious to learn more about your case. What sort added value do you see in building a plugin integration, versus using dynamic objects? The main case I’ve come across is the desire to update a source system.
That being said, we’re curious to see if others have decided to make their own app even if they COULD get a decent amount of usage with the Dynamic Objects and what went into deciding to put the resources into implementing a more thorough and time consuming process.
We’re also curious if anyone has utilized an integration app like Workato to make API integration smoother but that’s probably another conversation altogether!
+2We work with TMS software that isn’t accessible through the browser, so doing the Dynamic Objects doesn’t seem to be an option.
That makes sense. One enhancement we want to make in the future is to PRD-I-5743 Allow dynamic objects to be created without a target URL.
For what it’s worth, you can still get dynamic objects working with the following workaround... Configure a dynamic object with custom fields that pull TMS information from your API (shipment ID, status, location, etc.). Then, link the users to some dummy location, e.g. www.google.com. This would allow you to build a dynamic object without needing your TMS to live at some URL.
Anyways, I’ll cede the floor so others can weigh in on your other questions. Curious what others have to say about the factors that influence dynamic object vs plugin development!
Login to the community
No account yet? Create an account
Use your Front credentials
Log in with FrontEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.