03 / HOW I BUILD
From a business need to working logic.
Here is how I connect interfaces with data, rules, access and automation. Explore the engineering decisions here, and the full projects in their case studies.
Record & review
- 01
Create the risk record
Capture the business record in the application.
Power Apps - 02
Store the record
Risk data is stored in SharePoint.
SharePoint - 03
Maintain risk & mitigation details
Maintain the risk information and mitigation details in the application.
Power Apps - 04
Review within authorized access
Authorized GRC and business users review the record.
Access control - 05
Submit a comment
The reviewer adds comments or remarks.
Power Apps - 06
Save the comment
Store the submitted comment for follow-up.
Structured storage
Notification & follow-up
- 07
Notify the responsible person
Notify the authorized business stakeholder.
Power Automate - 08
Send context, not just an alert
Email includes the risk, mitigation/comment context and a deep link.
Microsoft 365 - 09
Return to the right record
The user follows the deep link into the application record.
Deep link - 10
Continue the review
The record continues through the business review process.
Power Apps
- 01User interface
- 02Oracle APEX Pages
- 03Business / application logic
- 04SQL / PL/SQL
- 05Oracle Database
Application areas
Data entities · illustrative names
PMISDemo project recordsDemo milestonesDemo progress recordsGRCDemo business teamsDemo risk recordsDESIGN DECISION
Show the latest status for each project.
Rank each project’s snapshots from newest to oldest, then select row 1 for its current status.
ROW_NUMBER() OVER (
PARTITION BY demo_project
ORDER BY demo_date DESC
)Retrieve risk details when selected
- APEX Page
- AJAX Process
- SQL / PL/SQL
- Oracle Tables
- Result returned to interface
Scattered files and milestone updates make definitions, ownership and performance calculations harder to keep consistent. I structure those relationships before designing the screen.
- 01Business requirement
- 02KPI data model
- 03Performance scope
- 04KPI definition
- 05Milestone structure
- 06Calculation rules
- 07Status management
- 08Role / access logic
- 09Reporting view
Illustrative demo rules
- Each KPI has its own milestones, with planned and actual values.
- KPI Actual sums valid milestone contributions; it is not entered manually.
- Planned milestone shares total 100%; their calculated weights sum to the parent KPI weight.
- Validate demo inputs and keep linked information consistent.
- Exclude deleted or cancelled milestones where appropriate.
- Illustrate status tracking and reporting with fictional records.
ILLUSTRATIVE EXAMPLE · KPI TO MILESTONES
Work plan completion
The KPI weight is split between two milestones according to their planned shares: 40% and 60%. Change each milestone’s actual completion to see its contribution to the KPI.
Milestone 1
- Planned share of KPI
- 40%
- Calculated milestone weight
- 10 × 40% = 4
Milestone 2
- Planned share of KPI
- 60%
- Calculated milestone weight
- 10 × 60% = 6
Overall KPI completion100%
At 100% completion for both milestones, contributions are 4 + 6 = 10: the full KPI weight. In this example, each milestone’s contribution is capped at its allocated weight.
From fragmented follow-up to connected work.
A conceptual comparison of my approach—not screenshots of a former system or a claim that every project replaced Excel.
BEFORE · MANUAL & FRAGMENTED
- Excel / files
- Separate updates
- Manual consolidation
- Limited visibility
- Reporting effort
AFTER · STRUCTURED ENTERPRISE SOLUTION
- Centralized data
- Business application
- Defined workflow
- Automated calculations / rules
- Role-based access
- Dashboards & reporting