39 karma · joined December 29, 2012
Could you elaborate on what you're trying to do with SSO? To clarify, you can SSO via Slack on any of our pricing plans (which in turn often SSO's with other providers). Essentially, whatever you SSO with on Slack, will work with incident.io.
If you'd like to use SAML, you can do that too, on our Pro plan and above. The only thing offered exclusively behind our Enterprise plan is SCIM.
I don't think they're always a bad idea, but when talking about external IDs many folks would agree with you, in a few ways, actually.
Relying on exposed primary IDs being ordered, and/or exposing them, is often a bit of a can of worms.
A common case is that you leak information about your company because people can see how quickly you're growing. I've seen this in a few products I use and it's always interesting when you take an action a few days apart and can see how much volume they're doing.
TIL: German Tank Problem, thanks @teddyh! I first came across it with a good story about someone buying Donuts/Coffee in a shop and using the receipt numbers to estimate yesterday's sales, can't find the link, though :(
In this instance it's not our primary ID field - those are internal, and are long and random. They holds no meaning other than being a reference, so aren't used for sorting or exposed to the customer, and even if it was, it wouldn't mean anything or confer any information.
The IDs I refer to the in the article are more like external references. References we _explicitly_ want to increment by 1 each time.
For those referencing invoices as a parallel, it's a good equivalent. I'm not familiar with the details in the comments below, but if I created two invoices and they were referenced #1 and #33, I'd be quite confused (which is a version of what our customers felt/experienced here).
IMO It's also often a good idea to use different external IDs to your internal ones in APIs too, and ideally have no meaning attached to them, either. That way users don't do things like assume "record 99" was created before "record 100", and you can also move data around and migrate things, so long as you honour those external references (i.e., you can change the type/format of your internal IDs at will).
Luckily our _internal_ IDs don't rely on sequences at all, and for ordering I'd always use a field specifically for that purpose like `created_at` timestamps etc (vs inferring ordering from IDs). Best if IDs just remain references!
This could have been another interesting bug though, in a way glad we hit this one instead and that it's now fixed so we don't hit this one in future!
We were very open, and our customers in this case were really understanding - just one of the reasons we love working with them!
Normally I'd agree with you, but in this case we're explicitly dealing with external IDs that we want to be incrementing.
Our internal IDs and API IDs actually follow a totally different approach, and hold no meaning other than as a reference :)