Add Activepieces integration for workflow automation
- Add Activepieces fork with SmoothSchedule custom piece - Create integrations app with Activepieces service layer - Add embed token endpoint for iframe integration - Create Automations page with embedded workflow builder - Add sidebar visibility fix for embed mode - Add list inactive customers endpoint to Public API - Include SmoothSchedule triggers: event created/updated/cancelled - Include SmoothSchedule actions: create/update/cancel events, list resources/services/customers 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
14
activepieces-fork/docs/handbook/hiring/compensation.mdx
Normal file
14
activepieces-fork/docs/handbook/hiring/compensation.mdx
Normal file
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: "Our Compensation"
|
||||
icon: 'money-bill-wave'
|
||||
---
|
||||
|
||||
The packages include three factors for the salary:
|
||||
|
||||
- **Role**: The specific position and responsibilities of the employee.
|
||||
- **Location**: The geographical area where the employee is based.
|
||||
- **Level**: The seniority and experience level of the employee.
|
||||
|
||||
<Tip>Salaries are fixed and based on levels and seniority, not negotiation. This ensures fair pay for everyone.</Tip>
|
||||
|
||||
<Tip>Salaries are updated based on market trends and the company's performance. It's easier to justify raises when the business is great.</Tip>
|
||||
26
activepieces-fork/docs/handbook/hiring/hiring.mdx
Normal file
26
activepieces-fork/docs/handbook/hiring/hiring.mdx
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Our Hiring Process"
|
||||
icon: 'user-plus'
|
||||
---
|
||||
|
||||
Engineers are the majority of the Activepieces team, and we are always looking for highly talented product engineers.
|
||||
|
||||
<Steps>
|
||||
<Step title="Technical Interview">
|
||||
Here, you'll face a real challenge from Activepieces. We'll guide you through it to see how you solve problems.
|
||||
</Step>
|
||||
<Step title="Product & Leadership Interview">
|
||||
We'll chat about your past experiences and how you design products. It's like having a friendly conversation where we reflect on what you've done before.
|
||||
</Step>
|
||||
<Step title="Work Trial">
|
||||
You'll do open source task for one day. This open source contribution task help us understand how well we work together.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Interviewing Tips
|
||||
|
||||
Every interview should make us say **HELL YES**. If not, we'll kindly pass.
|
||||
|
||||
**Avoid Bias:** Get opinions from others to make fair decisions.
|
||||
|
||||
**Speak Up Early:** If you're unsure about something, ask or test it right away.
|
||||
43
activepieces-fork/docs/handbook/hiring/levels.mdx
Normal file
43
activepieces-fork/docs/handbook/hiring/levels.mdx
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Our Roles & Levels"
|
||||
icon: 'layer-group'
|
||||
---
|
||||
|
||||
**Product Engineers** are full stack engineers who handle both the engineering and product side, delivering features end-to-end.
|
||||
|
||||
### Our Levels
|
||||
|
||||
We break out seniority into three levels, **L1 to L3**.
|
||||
|
||||
### L1 Product Engineers
|
||||
|
||||
They tend to be early-career.
|
||||
|
||||
- They get more management support than folks at other levels.
|
||||
- They focus on continuously absorbing new information about our users and how to be effective at **Activepieces**.
|
||||
- They aim to be increasingly autonomous as they gain more experience here.
|
||||
|
||||
### L2 Product Engineers
|
||||
|
||||
They are generally responsible for running a project start-to-finish.
|
||||
|
||||
- They independently decide on the implementation details.
|
||||
- They work with **Stakeholders** / **teammates** / **L3s** on the plan.
|
||||
- They have personal responsibility for the **“how”** of what they’re working on, but share responsibility for the **“what”** and **“why”**.
|
||||
- They make consistent progress on their work by continuously defining the scope, incorporating feedback, trying different approaches and solutions, and deciding what will deliver the most value for users.
|
||||
|
||||
### L3 Product Engineers
|
||||
Their scope is bigger than coding, they lead a product area, make key product decisions and guide the team with strong leadership skills.
|
||||
|
||||
- **Planning**: They help **L2s** figure out what the next priority things to focus on and guide **L1s** in determining the right sequence of work to get a project done.
|
||||
- **Day-to-Day Work**: They might be hands-on with the day-to-day work of the team, providing support and resources to their teammates as needed.
|
||||
- **Customer Communication**: They handle direct communication with customers regarding planning and product direction, ensuring that customer needs and feedback are incorporated into the development process.
|
||||
|
||||
### How to Level Up
|
||||
|
||||
There is no formal process, but it happens at the end of **each year** and is based on two things:
|
||||
|
||||
1. **Manager Review**: Managers look at how well the engineer has performed and grown over the year.
|
||||
2. **Peer Review**: Colleagues give feedback on how well the engineer has worked with the team.
|
||||
|
||||
This helps make sure promotions are fair and based on merit.
|
||||
28
activepieces-fork/docs/handbook/hiring/team.mdx
Normal file
28
activepieces-fork/docs/handbook/hiring/team.mdx
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "Our Team Structure"
|
||||
icon: 'users'
|
||||
---
|
||||
|
||||
We are big believers in small teams with 10x engineers who would outperform other team types.
|
||||
|
||||
## No product management by default
|
||||
|
||||
Engineers decide what to build. If you need help, feel free to reach out to the team for other opinions or help.
|
||||
|
||||
## No Process by default
|
||||
|
||||
We trust the engineers' judgment to make the call whether this code is risky and requires external approval or if it's a fix that can be easily reversed or fixed with no big impact on the end user.
|
||||
|
||||
## They Love Users
|
||||
|
||||
When the engineer loves the users, that means they would ship fast, they wouldn't over-engineer because they understand the requirements very well, they usually have empathy which means they don't complicate everyone else.
|
||||
|
||||
## Pragmatic & Speed
|
||||
|
||||
Engineering planning sometimes seems sexy from a technical perspective, but being pragmatic means you would take decisions in a timely manner, taking them in baby steps and iterating faster rather than planning for the long run, and it's easy to reverse wrong decisions early on without investing too much time.
|
||||
|
||||
## Starts With Hiring
|
||||
|
||||
We hire very **slowly**. We are always looking for highly talented engineers. We love to hire people with a broader skill set and flexibility, low egos, and who are builders at heart.
|
||||
|
||||
We found that working with strong engineers is one of the strongest reasons to retain employees, and this would allow everyone to be free and have less process.
|
||||
Reference in New Issue
Block a user