Why requests exist
Requests separate intent from approval. Employees can say, "I need this type of letter for this purpose," without immediately generating final output. That gives administrators a review point where they can verify completeness and accuracy.
Request lifecycle
- Pending: created by the employee and waiting for review
- Approved: converted into a generated letter
- Rejected: intentionally denied
What employees provide
Employees do not fill every placeholder in the template. They only fill placeholders marked as requester-supplied. These often represent purpose-driven or destination-driven values that cannot be known ahead of time.
Common requester-supplied examples:
[[purpose]][[recipient_name]]
How approval works
When an admin approves a request, the approval form loads placeholders by language. The system then checks whether requester-required fields are actually present. If any required value is missing, approval is blocked and a danger notification is shown.
Why this safeguard matters
Without this check, teams would approve incomplete requests, generate letters with missing content, and only discover the issue at print time. The approval safeguard moves the problem earlier in the workflow.
Request edge cases
- Employee already has a pending request for the same template: the employee panel intentionally blocks a second pending request.
- Template changed after request creation: admins should review whether the original request still matches the intended output.
- Some languages have more requester fields than others: the employee form will surface fields per language tab, which can surprise teams if they are not expecting it.
- Request values partially present: approval still fails if any requester-required value remains blank.
Operational advice
- Keep requester fields minimal. Only ask employees for what they truly know.
- Prefer model-driven placeholders for employee or company data that the system can already resolve.
- Review pending requests regularly so employees do not perceive the system as a black hole.
Approval quality checklist
- Confirm the selected template is still the correct document type.
- Check requester-provided values for spelling, specificity, and relevance.
- Confirm the employee belongs to the expected company.
- Review whether any auto-resolved values look stale or incorrect.
- Verify that the final output language set matches what the employee will need to print.
Why requests should not be bypassed casually
Direct letter creation is useful for special cases, but the request workflow gives you process visibility and accountability. If teams bypass requests for routine work, they lose the audit trail that explains who asked for a document and why it was created.