Business application guide
Business Application Development: from Spreadsheets to a Working System
Business application development has a sensible starting point when you can show which process needs fixing, who takes part in it and where data loses clear meaning today. Before building, write down the process states, record permissions, correction rules and the data to migrate. Then prove the whole flow on a limited example, through a trial migration and a pilot.
Start by mapping how a record moves through the work
A spreadsheet is not a reason for a new application on its own. It can serve a small team with simple rules well. An assessment becomes useful when you need to settle responsibilities, different access levels or a chain of steps that is no longer practical to track in the current way of working.
If the choice between buying, integrating and building is still open, see the guide to choosing a software solution. Here we deal with the next question: how to prepare a business process for an application.
Collect the last few completed cases and find their shared steps. Include the record that came back for amendment, was rejected or was corrected afterwards. Those cases reveal the rules the main spreadsheet rarely shows.
Identify the event that starts the work, the conditions for the next step and the finish. Keep a record someone entered separate from a record an authorised person confirmed.
In a hypothetical manufacturing team, batch inspection records sit in a spreadsheet while photos and amendments live in messages. A new business application should connect the record, the finding and the decision. This example does not describe an actual Novero delivery and does not promise a particular business result.
| Record state | What it means in the example | Condition for the next step |
|---|---|---|
| Prepared | The batch is ready for review | An inspector has been assigned |
| In review | Findings and attachments are being entered | Required checks are complete |
| Needs amendment | A data point or evidence is missing | The amendment has been resubmitted for review |
| Confirmed | An authorised person accepted the finding | Any further change follows the agreed procedure |
Drawing arrows is not enough. For every state change, state who triggers it and what the application should do if the condition is not met.
Keep business rules separate from screen design
A single screen can hold rules that matter to several departments. Changing a batch code, for example, can affect related findings and a report that has already been exported.
Before discussing colours and field layout, settle:
- what uniquely identifies a record;
- which fields must be entered and which must be confirmed;
- who corrects a wrong entry and how the previous value is shown;
- what happens to attachments and linked records;
- which exceptions are allowed and who approves them.
In the manufacturing example, you might agree that editing a confirmed finding opens a new version for review. Another process may need different behaviour. It should be a decision of the business process owner, written down clearly for development and testing.
Turn roles into a table of concrete permissions
An administrator who manages accounts does not need the business authority to confirm an inspection. An inspector can edit an assigned record, while a manager can see the results of several teams.
Prepare permissions for the action and the data it applies to. OWASP's authorization guidance recommends defining users, resources and permitted operations, and verifying those rules with tests.
| Role in the hypothetical example | Permitted action | Constraint to verify |
|---|---|---|
| Operator | Prepares the batch record | Does not confirm the inspection finding |
| Inspector | Enters a finding on an assigned batch | Does not change someone else's confirmed finding without a correction procedure |
| Quality manager | Confirms or returns a finding | The reason for returning stays linked to the record |
| Account administrator | Assigns agreed access | Administration is not a shortcut to business approval |
The table is a proposal for requirements. The real organisation needs to confirm responsibilities and possible substitutions, including small teams where one person handles several roles.
Clarify what the data means before migration
Do not assume a column from the old spreadsheet can become a field of the same name in the new application. The label “finished” may have meant a completed entry in one team and a confirmed result in another.
For every data point, write down the source, meaning, allowed values and the person who can resolve an ambiguity. Agree whether to carry over history, open items, attachments and links between records.
Microsoft's guidance for migration to Dynamics 365 covers sources, mapping, sequence, responsibilities and quality checks. It is a useful planning model, adapted to your actual systems.
Being able to export to CSV is not proof that the migration is solved. Check the relationships between records, date formats, identifiers, character encoding and how attachments are handled. If data is being taken from another business tool, also assess connecting existing systems.
Run a trial migration and reconcile the result
For the trial, pick data that covers different states and several known problems. In the test environment, use appropriately protected or prepared data; do not share personal or business secrets unnecessarily.
Suppose the test set has 120 records. If 117 were migrated and three were rejected, that result can explain the starting count, but the migration is not yet confirmed as complete. You need to see why the three records were rejected and what was decided about them. The numbers serve only to explain the check.
A trial checklist can include:
- Reconciling the number of source, migrated and rejected records.
- Checking whether the same labels or codes created duplicates.
- Opening selected records and their attachments.
- Checking the links between batches, findings and users.
- Comparing important views with the agreed source data.
- Confirming by the responsible person that discrepancies are resolved or documented as accepted.
A row count is not the only check. Equal numbers can hide wrongly linked data or different interpretations of a status.
Tie the pilot to the team's real tasks
Choose users who can complete the whole flow, including amendment and correction. Agree whether their work during the pilot is trial or already official, and where the valid record for that period lives.
During the pilot, log difficulties in understanding, software defects and new business rules separately. A user who does not know why a record was returned may need a clearer message. A request for extra approval may require a scope change.
Before the whole team moves over, check access, short work instructions, who to ask and how data corrections are handled. For the old way of working, agree when entry stops and how history is accessed according to real needs; do not delete it just because the new system has started.
The first version should close the process you selected
For the initial scope, choose a flow whose completion can be recognised. In the inspection example, that includes preparing the record, the finding, the amendment and the confirmation. Advanced analytics can wait if it is not a condition of that work.
When preparing custom business applications, flag unresolved decisions clearly. An unknown rule or unclear piece of data is something to analyse further, not a reason for the vendor to assume how you do business.
Send Novero one described workflow and an anonymised example of the current records. With the list of roles and open questions, you can start a conversation about an application that supports real work.
Sources
- OWASP: Authorization Cheat Sheet — defining users, resources and permitted operations, and verifying the rules with tests.
- Microsoft: data management and configuration data migration for Dynamics 365 — planning sources, mapping, sequence, responsibilities and quality checks.