What does a Power Automate developer do day to day?
A Power Automate developer builds flows: automated sequences in Microsoft's Power Automate service that react to events in Microsoft 365 and other systems, apply your rules and update records or notify people. Most of the work is less about clicking actions together and more about turning an informal office habit into explicit steps.
Take a purchase request. Today someone fills a form or sends an email, the department head replies “ok”, finance asks for a quotation, the director approves anything above a limit, and procurement raises the order. Nothing is written down, reminders depend on memory, and nobody can say where a request is stuck. A flow can capture the request in a SharePoint list, route it by amount and department, wait for each response, remind approvers, record every decision with a timestamp and tell the requester the outcome.
The other half of the job is housekeeping that non-specialists skip: building flows inside solutions, giving them shared owners and service connections, adding error handling, and checking which connectors your licences cover. Those habits decide whether a flow still works in a year.
- Approval chains with conditions, reminders and escalation
- SharePoint list and document library workflows
- Excel Online updates and scheduled Office Scripts
- Outlook and shared mailbox processing
- Teams adaptive cards and channel alerts
- Desktop flows for software without connectors
Cloud flows vs desktop flows: which does your process need?
Use cloud flows when the systems involved have connectors or APIs, which covers most of Microsoft 365; use desktop flows only when you must drive software through its screen because no connector or API exists. Cloud flows run in Microsoft's cloud. Desktop flows run on a Windows machine through Power Automate for desktop.
Microsoft's documentation describes desktop flows as its robotic process automation capability, able to work with legacy applications such as terminal emulators, modern web and desktop apps, Excel files and folders, by interacting with UI elements, images or screen coordinates. That flexibility has a cost: a desktop flow breaks when a screen layout changes, needs a machine that is switched on and signed in, and is slower than an API call.
So the order of preference is simple. First, a standard connector. Second, a premium or custom connector if the licence cost is justified. Third, a desktop flow for the one screen nothing else can reach. Many real projects combine them: a cloud flow handles the approval and SharePoint record, then triggers a desktop flow that keys the approved entry into an old billing application. For wider screen-based work across portals, our RPA automation page goes deeper.
Cloud flow triggers
Automated (an event such as a new list item or email), instant (a button in Teams or on a phone) and scheduled (every morning at 9, every month end).
Desktop flow run modes
Attended, where a person is signed in and watching, and unattended, where a bot signs in to a machine by itself. Unattended needs a capacity licence.
Power Automate licensing explained: what your Microsoft 365 plan already covers
Many useful flows need no extra licence: Microsoft's licensing documentation says the Power Automate Free licence, available to work or school accounts, covers creating and running cloud flows with standard connectors and running desktop flows locally in attended mode. The line is crossed when a flow needs premium or custom connectors, unattended bots or an on-premises data gateway.
According to Microsoft Learn, a Power Automate Premium user licence adds premium and custom connectors, one attended RPA bot, on-premises data gateways, process mining and AI Builder credits. A Power Automate Process licence is a capacity licence assigned to a cloud flow or a machine: it lets that flow use premium connectors regardless of who triggers it, or turns a machine into an unattended bot that runs one desktop flow at a time. Microsoft also notes that a flow must sit in a solution before a Process licence can be assigned to it. A Hosted Process licence adds a Microsoft-hosted machine so you need no physical PC for the bot.
In practice this is where a Power Automate developer earns the fee before writing a flow. An approval flow using SharePoint, Outlook, Teams and Approvals stays on standard connectors. The moment it calls an HTTP endpoint or a SQL database, licensing needs a second look. We list every connector per flow in the quote and mark which ones change your licence bill.
Licence names, entitlements and limits change from time to time, so we confirm against Microsoft's current documentation during the quote and suggest you verify prices with your reseller.
How a Power Automate developer builds approval flows with Teams notifications
Approvals are the most requested Power Automate job, and Microsoft's Approvals connector is a standard connector, so any licence that includes standard connectors, including Office 365 plans, can create approval flows, according to Microsoft Learn. Approvers can respond from an Outlook email, a Teams adaptive card or the Power Automate action centre.
Microsoft lists several approval types. Approve/Reject with everyone must approve waits for all approvers, though a single rejection ends it. Approve/Reject with first to respond completes on any one answer. Custom responses let you define options like “Approve”, “Send back” or “Need quotation”. Sequential approval asks people one at a time in a set order.
Real processes rarely fit one type. A common pattern is a department head as the first step, then a condition on amount: below the limit goes straight to finance; above it goes to the director. Rejections send the request back to the requester with comments. A parallel branch waits a set number of days and sends a reminder if nobody has answered, then escalates. Every decision is written back to the SharePoint list so the requester can check status without chasing anyone.
Two practical notes. Approvals store their data in Dataverse, and Microsoft says the first approval flow in a non-default environment provisions a database, which needs an environment administrator. And approvers who are guests from another tenant must have accepted their invitation, or they drop out of the approval.
SharePoint lists and Excel files: getting the data layer right
Choose a SharePoint list over an Excel file whenever several people or flows write to the same data; Excel is fine for a report a flow reads or appends to occasionally. That one decision prevents most of the flow failures we are asked to repair.
Microsoft's documentation for the Excel Online (Business) connector lists limits worth knowing before you design around a spreadsheet. The data must sit in a formatted table. The List rows action returns 256 rows by default unless pagination is turned on. Supported files are up to 25 MB. A file may be locked for up to six minutes after the connector last used it, and simultaneous edits from Excel, other flows or apps are not supported and can cause conflicts.
SharePoint lists handle concurrent writes far better, keep version history, support column validation and permissions, and are designed for this kind of record keeping. We often start a project by moving a shared tracker from an Excel file into a list, keeping an Excel export or a Power BI report for people who like to see the data in a grid.
Where Excel logic itself must run, a flow can call an Office Script. Microsoft notes that VBA has no Power Automate connector, so desktop macros cannot be triggered by a cloud flow; Office Scripts can, and the connector's Run script action also works on .xlsm files.
Can Power Automate process Outlook emails and attachments?
Yes. A cloud flow can watch a mailbox or shared mailbox, filter by sender, subject or attachment type, save attachments to SharePoint or OneDrive, log details in a list and send a reply, all with standard Office 365 connectors in most cases.
Typical examples in Indian offices: vendor invoices arriving at accounts@ are saved to a monthly folder with the vendor name in the file name and logged for payment approval; purchase orders from key customers create a task for the sales coordinator; bank or payment-gateway settlement reports are filed automatically for reconciliation; and HR's inbox acknowledges every job application with a standard reply.
The hard part is not the trigger but the variety of incoming mail. Vendors change subject lines, send three attachments where one was expected, or forward chains. A good Power Automate developer builds tolerant filters, sends anything unrecognised to a review folder instead of dropping it, and avoids loops where a flow's own reply triggers the flow again. When invoices need their fields read, not just filed, AI extraction is a separate step, covered on our invoice processing automation page.
Connecting Power Automate to Tally and your ERP
There is no Microsoft connector for Tally, so linking the two needs a bridge: TallyHelp documents XML and JSON requests to TallyPrime over HTTP, and ODBC for reading data, but TallyPrime typically runs on a local PC or server that Microsoft's cloud cannot reach directly.
Three routes work. An on-premises data gateway lets cloud flows reach systems on your network; per Microsoft's licensing page, gateways are a Premium entitlement. A desktop flow on the Tally machine can export or import data locally and hand results to a cloud flow. Or Tally exports a scheduled file to a synced OneDrive folder, and a cloud flow picks it up. The third route is the cheapest and often enough for daily reports; the first suits near-real-time needs such as posting approved vouchers.
ERPs vary. Cloud ERPs with a REST API can use a custom connector or the premium HTTP action. Older on-premises ERPs follow the same pattern as Tally. Before recommending any route, we ask whether your ERP vendor offers an official integration, because writing into accounting data through the screen should be a last resort. Our Tally API integration and ERP developer pages cover deeper builds.
- Scheduled export to a synced folder: simplest, standard licence, daily data
- Desktop flow on the Tally PC: works without network changes, needs a signed-in machine
- Gateway plus custom connector: near real time, needs Premium licences
- Vendor's own integration or API: preferred where it exists
How much does a Power Automate developer cost in India?
With BtechWaleTech, Power Automate projects start at ₹40,000 (about US$600 for international clients), and most approval or list workflows finish in two to four weeks. Other freelancers and partners charge by the hour, day or project, and quotes vary widely, so compare scope, licence planning and documentation rather than the figure alone.
The build cost rises with the number of flows and branches, the number of approval levels and exception paths, integrations beyond Microsoft 365, desktop flows, and the documentation standard your IT team requires. A single leave approval is small. A procurement workflow with four levels, budget checks against a list, vendor emails and a Tally entry is several times larger.
Licence costs are separate and sometimes zero. If every connector is standard and your staff already have suitable Microsoft 365 plans, the flows cost nothing extra to run. Premium connectors, unattended bots or gateways add licences, which is exactly why we map them flow by flow before building. After the two free months, maintenance starts at ₹8,000/mo if you want someone watching run history and adjusting flows as the business changes.
Power Automate governance: owners, solutions and data policies
Governance means your flows keep running when people leave, cannot leak data to the wrong service, and can be found and changed by the next developer. For small tenants it needs a handful of habits, not a committee.
First, ownership. A flow built under one employee's account, with connections using their login, breaks when their account is disabled. We build flows inside solutions, add a second owner, and use a dedicated service account for connections where your licensing allows it.
Second, data policies. Microsoft describes Power Platform data policies as guardrails where administrators group connectors so business data cannot flow into non-business services, or block connectors outright. Microsoft notes that flows violating a changed policy are suspended, and that full enforcement can take up to 24 hours, though usually under an hour. We check your policies before building so a flow is not suspended the week after launch.
Third, environments. Serious flows belong in a dedicated environment rather than the default one everyone can use, with a separate test environment if you change flows often. Fourth, naming and documentation: a consistent naming pattern and a one-page map per flow saying what triggers it, what it touches and who to call.
- Flows inside solutions, with at least two owners
- Connections through a service account where licensing permits
- Data policies reviewed before build, not after suspension
- Production flows kept out of the default environment
- Failure alerts to a shared mailbox, not one person
- A one-page map for every flow
What happens when a flow fails, and how do you know?
By default a failed cloud flow simply records a failed run, and the owner may get a digest email; nobody else notices until a customer or manager complains. A well-built flow catches failures, retries where sensible and tells a named person what went wrong.
The standard pattern uses scopes: the main steps sit in a “Try” scope, and a “Catch” scope configured to run only when the first one fails sends an alert with the run link and the error message. Actions calling external systems get retry policies. Long waits, such as approvals left for days, have timeouts with an escalation path instead of hanging forever.
Limits matter too. Microsoft sets daily action limits per licence; its licensing page lists 40,000 actions per day per Premium user and 250,000 per Process licence. A flow looping through thousands of rows every hour can approach those limits. The fix is design: filter at the source, use batch operations, and trigger on changes rather than scanning everything. A Power Automate developer should be able to estimate a flow's daily actions before it goes live.
How to choose a Power Automate developer
Choose a Power Automate developer who asks about your licences, your environments and your IT policies in the first conversation. Anyone can drag actions onto a canvas; knowing whether the result will be allowed to run in your tenant is the real skill.
Useful questions: Which of these flows need premium licences, and for whom? Will you build in a solution with shared owners? How will I know when a flow fails? What happens to the flows if the employee whose login they use leaves? Can you work within our data policies? What will our IT team receive at handover?
Good answers name specific connectors and licence types, mention scopes and failure alerts, and offer solution exports plus a flow map. Warning signs include asking for a global administrator account without explaining why, building everything under one personal login, or promising that “everything is included in Office 365” without checking a single connector.
- Lists connectors per flow and marks premium ones
- Works with the least admin rights needed
- Builds in solutions with shared owners
- Adds failure alerts and retry policies
- Hands over exports and documentation your IT team can read
From first call to live flows: a typical three-week plan
Most projects go live in two to four weeks: a few days to map and quote, one to two weeks to build and test in your tenant, and several days of supervised running with real requests.
Week one: a call where your team shows the current process, including the exceptions (what happens when the approver is on leave, when an amount is edited after approval, when a vendor sends the wrong format). We confirm licences, environments and data policies with your IT contact, then send an itemised quote in about two working days. Nothing is billed until you approve it in writing.
Week two: flows are built in a test environment or clearly named test copies, with a test SharePoint list and test approvers. Your team tries every path, including rejection and escalation. Week three: flows are moved into production as a solution, connections switched to the service account, and the first real requests are watched closely. Once a week passes cleanly, the old manual route is retired and the admin notes are finalised.
Who owns the flows, and what do you receive at handover?
Your organisation owns every flow, list, script and connection, because they live in your Microsoft 365 tenant from the first day. We work through a guest or member account that your administrator creates and can remove at any time.
At handover you receive the solution export of the flows, which your IT team can import into another environment; a flow map for each flow showing trigger, conditions, connectors and outputs; a licence note listing which users or flows need which licence and why; and admin notes on failure alerts, service accounts and how to pause a flow safely.
If your team wants to maintain the flows themselves, we can walk a nominated person through each one on a recorded call. Change and payment terms are agreed in your written quote; the general basis is on our terms page. And if later you move away from Microsoft 365, the flow maps become the specification for rebuilding the process elsewhere, for example with Make or custom code.
Power Automate developer services across India
We work remotely with Microsoft 365 customers across India, and the tenant matters more than the city. Still, some patterns repeat. Finance and shared-service teams in Mumbai, Hyderabad and Bengaluru ask for invoice routing and month-end approval chains.
Manufacturers in Pune, Nashik and Aurangabad want purchase requisitions, quality deviations and maintenance requests tracked in SharePoint. Hospitals and colleges in Thiruvananthapuram and Coimbatore route leave, procurement and document approvals. IT services firms in Gurgaon and Chennai automate onboarding and access requests.
Wherever you are, the method is the same: a screen-share walkthrough, access granted by your administrator, a shared WhatsApp group or Teams chat for questions, and daily notes during the first live week. We do not visit offices, and a Power Automate developer never needs to; the whole build happens inside your tenant.
Worked example: a hypothetical Pune manufacturer's purchase approvals
Say a 120-person auto-component manufacturer in Pune runs purchase requisitions through email and a shared Excel sheet, and orders are delayed because nobody knows who is holding an approval. This scenario is illustrative, not a client story.
The rebuild would move the tracker into a SharePoint list with validated columns: department, item, quantity, estimated amount, preferred vendor and attachment. A Microsoft Form or the list's own form captures new requests. A cloud flow starts on each new item.
Step one sends a Teams adaptive card to the department head. On approval, a condition checks the amount: below the set limit, finance receives the next approval; above it, the plant head is added in sequence. Rejections return to the requester with comments. A parallel branch sends a reminder after two working days and escalates after four. Each decision is written to the list, and the requester gets a Teams message at every stage.
Everything here uses standard connectors: SharePoint, Approvals, Teams, Outlook and Forms, so staff with suitable Microsoft 365 plans need no extra licences. If the company later wants approved requisitions posted into Tally automatically, that step would add a gateway or desktop flow and the licence discussion that comes with it.
Checklist before you hire a Power Automate developer
Have these ready and the first call becomes a design session. Rough answers are fine; we fill the gaps together.
- Your Microsoft 365 plan names and roughly how many users hold each
- Whether anyone already has Power Automate Premium or Process licences
- The process steps, approvers and amount or category rules
- Where the data lives today: Excel file, SharePoint list, email, ERP
- Systems outside Microsoft 365 that must be updated
- Any existing data policies or restrictions set by IT
- Who should receive failure alerts
- A contact in IT who can create an account and approve connections
- Whether the process has exceptions for leave, delegation or urgent cases
- Preferred language for staff guides: English or Hindi
Send these on WhatsApp or email and you will get a flow plan, licence note and itemised quote in about two working days. If Microsoft 365 is not the right home for the process, the plan will say so and suggest another automation route.