Manage Endpoints for Campaign

[stevejgordon]

Once we add features to update getasmokealarm as status changes occur in requests, do we need a way to flag a campaign as having a service endpoint?

While we have a single campaign this shouldn't be an issue but in the future we wouldn't want to try and update getasmokealarm each time a status changes on a request for a different campaign.

[tonysurma]

Yes we need some way to flag this and tie them. cc @MisterJames @mgmccarthy

[stevejgordon]

I'll grab this one and try to add something basic to get us going. I'm thinking a table to hold details of the service integrations we support. Each integration would be tied to an Org.

e.g.
Id - 1
Name - GetASmokeAlarm
Org - Red Cross

Then, when creating a campaign an Org Admin can select from any of their available integrations (or leave empty) for the new campaign.

We would then use this integration information wherever we may need to make integration calls. A basic approach would be to check what, if any integrations, we need to work with. This could get quite complicated as the GASA is quite tied to our flow right now.

Just opening up for thoughts before I start working on this.

/cc @mgmccarthy

[mgmccarthy]

I agree with a higher-level approach like this...

I'd like to optimize/aim for what makes sense to our users that are org admins and make it easy on them.

On a high level, I'd like to see a single exposed endpoint that would accept all Requests, regardless of vendor, and use that endpoint as a routing mechanism to perform the lookup for the type of Request integration, then forward the request to the any code that would need to be written for that particular integration.

[mgmccarthy]

questions for @tonysurma @mikesigs @OhMcGoo

is it possible for one integration (let's say the importing of Requests right now) to be used across multiple organizations? I'm assuming the answer to this is yes, but I was just chatting with @stevejgordon about it.