1. Define the application

1.1 Requirements

Write these down before opening Studio (one page is enough):

Question	Leave Management answer
Business problem	leave is tracked in email and spreadsheets; balances are wrong; approvals get lost
Users and roles	employees, managers, HR administrators
Main use cases	request leave, approve or reject, see balance, manage leave types, report on leave
Functional	leave types with yearly entitlement; request with dates and reason; two-step approval; balance per employee per year
Non-functional	works on phones; approvals answered within 2 days; auditable
Integrations	payroll export (later)
Compliance	keep an audit trail; employees see only their own leave
Reporting	leave summary, by department, monthly trend, exceptions

1.2 Application specification

Item	Value
Plugin id	leave-management (lowercase, digits, dashes; cannot change later)
Name	Leave Management
Version	1.0.0
Vendor / license	Acme Corp / Proprietary
Category	custom
Dependencies	none (HCM's employee data is referenced by id)
Structure	Employees, Leave Types, Leave Policies, Leave Requests, Approvals, Balance, Calendar, Reports

1.3 Create it in Studio

1. Create new, Plugin (the wizard).
2. Name, then type:

Type	Choose when
Full application	a complete module with data, screens and roles (this one)
UI plugin	only screens over existing data
Backend / service plugin	logic in code, optionally its own container
Integration	connectors and integration flows
Extension	enhancing an installed plugin
Country / industry pack	localized rules and forms

3. Add the first data, roles, screens (you will refine them in the next chapters).
4. Create plugin. This is your development environment: a workspace you can validate, snapshot and publish.

Details: Create a plugin.

1.4 Design the architecture

Application
 |- UI (pages, forms, dashboards)      what people see
 |- Entities                           the records
 |- Services and APIs                  how data and logic are reached
 |- Workflows                          multi-step, multi-person
 |- Events, jobs, queues               things that happen, run on time, run later
 |- Reports and integrations           output and outside systems
 |- Security                           who can do what

Decide these before building:

Question	Rule of thumb
What belongs in this application?	one business capability; reuse HCM's employees instead of copying them
Reusable or extension?	a common piece (approval pattern, block) is reusable; a company-specific change is an extension
API or screen-only?	expose an API only if another system needs it
Synchronous or asynchronous?	a check that must block a save is synchronous (rule); slow or optional work is asynchronous (workflow, job)
Workflow or rule?	one check on a save is a rule; several people over days is a workflow
Scheduled job?	anything triggered by the clock, not by a person

Next: Data and security first.