[harshithmul]

Yeah, I think we have 2 things here. Take an example model a "Ticket".

1. Dealing with custom fields. We provide a way you can map the custom fields specific to the company into the common Model.

2. Dealing with the naming difference Github has issues and Asana has Tasks. We map both the data into a common Ticket model.

This ensures that you integrate with our Ticketing Model and you are integrated to all the Ticketing platforms we support

[tuckerconnelly]

Maybe ticket isn't a great example. Another general problem I've had with mappings is say, one service uses a one-to-one relationship, and another puts both entities into a single entity. E.g., maybe there's a way to share tickets externally. One allows you to create a shareable link as a separate entity, and another embeds the shareable link as a property of the ticket.

I think, looking at this, I'd still probably prefer to create something custom. What would really help is simplifying having to set up OAuth and api calls, and just being able to do the mapping (or transform, of extract-transform-load) myself, in case there are edge-cases.

[harshithmul]

gotcha.

We do the ETL in the background and ensure that the model is completed irrespective of the 1-1 or different entity. You would also be doing the same if you manage the ETL. You could check (https://github.com/poozlehq/poozle/tree/main/integrations/ti...) our ticketing integrations, would love to take some feedback there.

Also if you need more customization you can write on top of the integration we have already (https://github.com/poozlehq/poozle/tree/main/integrations/ti...) and plug it into the platform.

[SparkyMcUnicorn]

If I'm understanding Poozle correctly, you could pull "tickets" from multiple services, join them, then send back a new "ticket" that might be in a different collection?

[harshithmul]

Yeah true. We will pull all similar tickets from multiple SAAS tools and send them back in a common ticketing model