search

calcom / cal.com

Scheduling infrastructure for absolutely everyone.
https://cal.com
Other
31.74k stars 7.73k forks source link

[CAL-3414] App: Lever.co #3717

Open PeerRich opened 2 years ago

PeerRich commented 2 years ago

similar to Greenhouse

CAL-3414

Udit-takkar commented 2 years ago

can you provide some more details about this required app?

PeerRich commented 1 year ago

if anyone wants to pick this up, here's how to make an app: https://docs.cal.com/how-to-guides/how-to-build-an-app

PeerRich commented 1 year ago

/bounty

algora-pbc[bot] commented 1 year ago

💎 $200 bounty • Cal.com, Inc.

Steps to solve:

  1. Submit work: Create a pull request including /claim #3717 in the PR body to claim the bounty
  2. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to calcom/cal.com!

Add a bounty • Share on socials

algora-pbc[bot] commented 1 year ago

You have a new bid! Click here to see.

algora-pbc[bot] commented 1 year ago

💎 $200.00 bounty created by PeerRich after accepting @PeerRich's bid 👉 To claim this bounty, submit a pull request that includes the text /claim #3717 somewhere in its body 📝 To receive payouts, complete Stripe Connect on your Algora dashboard 💵 Payment arrives in your account 2-5 days after the bounty is rewarded 💯 You keep 100% of the bounty award 🌳 If you want, you can donate 100% of the rewards to climate change projects! 🙏 Thank you for contributing to calcom/cal.com!

JatinRanka commented 1 year ago

@PeerRich Can you provide what features are required for this app? I would like to pick this up.

PeerRich commented 1 year ago

if connected, the incoming bookings should go to lever.co into the application column

PeerRich commented 1 year ago

i think we should use https://merge.dev

https://docs.merge.dev/ats/applications/

rjackson commented 1 year ago

I've been looking into this one today, building a Merge app to fulfil this PR as well #1549

Merge supports both CRMs and ATS', but I'm just exploring their ATS side of things for now – given the scope of these issues.

It looks like we'll be able to log Candidates (bookees) and Activities (the booking) through their APIs, which will then feed into whatever upstream ATS customers are using.

I'm also using Workable as the upstream ATS provider for now. Merge.dev suggests them during onboarding as they have developer accounts available, whereas Lever.co do not. I assume that's okay, given we're handing off the responsibility of ATS integration specifics to Merge?

rjackson commented 1 year ago

Going to park this for now. I don't think Merge makes this as simple as I thought it was going to be.

When integrating with Merge, our users have to choose what "Linked account" they're using for the integration – the linked account pointing to which of various upstream providers the user's wanting to keep in sync.

Each provider has their own varying set of supported and required fields when creating records. For example, with some providers we have to create an Application before we can create a Candidate record, whereas in others we must create the Candidate and then the Application. And some systems can support multiple applications for the same candidate, so there's possibly the need to resolve which existing applications might be appropriate to use rather than creating a new one.

Long story short, I feel like it's getting complicated. Not impossible, but not quite as simple as I interpreted "unified API". I don't think I'm going to have the time to fully explore this rabbit hole.

May be value in bringing the idea back to just a few provider-specific integrations. We'll lose the breadth of support Merge would give, but it should be simpler code, and potentially less of a blocker to customers (If they have Cal.com and Lever, having to procure & pay for Merge could be an issue?)

harisudarsan1 commented 1 year ago

@PeerRich I'll try to implement this

harisudarsan1 commented 1 year ago

@PeerRich Can you point out any examples from our codebase so that it will be easier for me to integrate.

PeerRich commented 1 year ago

Going to park this for now. I don't think Merge makes this as simple as I thought it was going to be.

When integrating with Merge, our users have to choose what "Linked account" they're using for the integration – the linked account pointing to which of various upstream providers the user's wanting to keep in sync.

Each provider has their own varying set of supported and required fields when creating records. For example, with some providers we have to create an Application before we can create a Candidate record, whereas in others we must create the Candidate and then the Application. And some systems can support multiple applications for the same candidate, so there's possibly the need to resolve which existing applications might be appropriate to use rather than creating a new one.

Long story short, I feel like it's getting complicated. Not impossible, but not quite as simple as I interpreted "unified API". I don't think I'm going to have the time to fully explore this rabbit hole.

May be value in bringing the idea back to just a few provider-specific integrations. We'll lose the breadth of support Merge would give, but it should be simpler code, and potentially less of a blocker to customers (If they have Cal.com and Lever, having to procure & pay for Merge could be an issue?)

yeah we decided against merge too. mostly because some self-hosters don't want to use merge and instead the "native" API key directly

giteshsarvaiya commented 6 months ago

if connected, the incoming bookings should go to lever.co into the application column

So that the calender in lever.co shows that the person is already booked for that specific time ? Am I right ? @PeerRich

MuhmdAjeer commented 1 month ago

hey @PeerRich, is this still open ?

Aniket-508 commented 2 weeks ago

@PeerRich, if this is still open I would love to give it a shot!