Open APIs

Hi,

We are looking to create a central task capability in which work for desk agents, planners and other employees (which may be created from decomposition of orders or faults from orchestration systems, inbound contact, complaints etc) can be aggregated and then allocated based on skill, product, location etc. Systems can contribute to the pool and then make calls for the next best action for an individual.

There is a work order API but that doesn't go as far needed for some of these requirements and wondered if there were any plans to develop APIs for this sort of thing or look to find interested parties to define one? Ours likely to be based on SalesForce as a backend and they have their own APIs but think there are probably others who may be looking at similar things and would prefer to use a TMF API to decouple us from a specific vendor, should we look to change in the future.

So looking again there is a work qualification management API which can allocate work to employees but does cover skills and work allocation so think this may actually be covered so will start to look at that.

Hi Steve,

I've worked on something similar where we needed a central task pool that could handle work coming from multiple systems and allocate based on skills, region, and product type. In my case, the backend was Salesforce, but we had to keep it vendor-agnostic for future flexibility. 
What worked well was combining TMF's Work Management / Task APIs with Salesforce's native task APIs, then layering in orchestration logic. For example, we pulled work from external systems, normalized it through a lightweight service layer, and pushed it into Salesforce for allocation. This gave us flexibility to change backend vendors later if needed.
Interestingly, I ran into the same pattern when building a monday.com Salesforce integration. Salesforce had the APIs, but we needed an abstraction so that if the backend changed, monday.com didn't break. A similar approach could apply here: define a TMF-aligned abstraction (task domain API) and let Salesforce handle the execution behind the scenes.

If there isn't a specific TMF API today that covers your whole use case, you could extend Work Order APIs or propose a new Task Management API through the forum. From experience, investing in a decoupled abstraction layer pays off in the long run, especially when orchestration and multiple contributors are involved.

Regards,
Maxwell

Hi, thanks for the comment. I've come to more or less the same conclusion, I'm working on a proposal for broadband with the TMF so this has been pushed back a bit, but will probably re-visit making proposals at a later date.

Hi Steve,

That makes sense, especially if the broadband proposal is taking priority right now. When you do revisit this, one thing that might help is documenting the "common denominators" across your contributing systems before diving into API design. In my case, that exercise clarified which elements could sit in a TMF-aligned abstraction layer versus what should stay vendor-specific (like Salesforce task objects).

If you push forward with a Task Management API proposal, I'd be happy to compare notes from the work we did combining TMF and Salesforce APIs. Sometimes just mapping out skill-based allocation and orchestration patterns upfront makes the standardization effort much smoother.

Regards,
Maxwell