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.
PMIS_Users_Comments
Notification & follow-up
- 07
Notify the responsible person
Notify the Champion or responsible 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
PMISPROJECT_MASTERPROJECT_MILESTONEPROJECT_MILSTONE_TXNGRCPMIS_DEPARTMENTSPMIS_RISKSDESIGN 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 PROJECT_ID
ORDER BY DATA_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
- 03Department / corporate structure
- 04KPI definition
- 05Milestone structure
- 06Calculation rules
- 07Status management
- 08Role / access logic
- 09Reporting view
Rules the solution enforces
- 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.
- Generate KPI identifiers systematically and control department/division relationships.
- Exclude deleted or cancelled milestones where appropriate.
- Apply the agreed status process and support department-level reporting / export.
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