Dynamics 365 Field Service integration with Finance & Operations applications | FastTrack Tech Talk
Good morning, good afternoon, good evening, wherever you're joining us from. Thanks for joining us today as we present today's TechTalk on field service integration with finance and operations. To present today's session, I'm Jason Cohen.
I'm a senior technical program manager for Frontline. I'm joined by my colleagues Guido Rennock, principal software engineer, and Harsh Brila, who is Dynamics 365 FastTrack solution architect. So in today's session, we'll first cover the business architecture and business overview of system architecture for the field service and FNO operations integration.
Then we'll walk through a demo, review extensibility options, highlight some of the implementation best practices, and then we'll talk about some additional resources. And at the end, we'll have some time for Q&A. So first, let me talk a little bit about why we built this. By combining these two solutions, field service and with finance and operations applications, we automate the connection between the front and back office, significantly reducing the need for manual data entry. We think this not only speeds up business operations, but also minimizes the chance of errors.
We think another key benefit of this integration is tracking field service operations and financial performance. Customers get a real time view of the impact of their field service operations, their field service activities on financial and inventory data in the system of record for those specific processes. This visibility should help both sides of the business stay informed and, we think, make make timely decisions in terms of accuracy and customer experience.
Integrating these systems drastically lowers the risk of data entry errors. Accurate financial records are, of course, crucial for compliance and overall business health. Ultimately, we think all these factors contribute to better customer satisfaction. So we went into this with, with a couple of key objectives. We wanted to deepen the power of our combined Dynamics 365 brand.
We wanted to offer a cost effective approach for our customers who use both field service and finance and operations in a way that makes sense. We also know, of course, that our customers care deeply about increasing the return on their investment, connecting their front and back office, reducing their implementation timelines, and limiting the risks in their implementations. We think we've achieved that. So this feature requires no unnatural licensing.
If you use field service, you need a field service license, even if the data ultimately makes its way into f and o. If you use f and o, you need relevant fno licensing, even if the data you're using came from FSD. I think about it this way, which is if you open the interface for that system, you still need a license for that.
Otherwise you don't need the license for both. We also think that this feature significantly reduces the risk, reduces risks to the implementations, reduces time to value, and increases ROI by simplifying customer integration efforts, which obviously if you don't have to build everything from scratch, that can be done more quickly. That can be done quickly, that can be done with less risk. And of course we think doing it more quickly and ideally with less effort increases ROI. We think this feature definitely improves the interconnectedness between the front and back office. As you'll see in the demo, your data lands where it's supposed to, which is the whole point.
Let me take just a couple of minutes to talk about our key principles for the integration. Of course, the first and highest principle is reliability over everything. If we lose a transaction or create false transactions at FNO, that's the worst thing we could do.
We built this to ensure accuracy across the two platforms. We automatically retry transactions. We have a framework that doesn't rely on sequential, discretely packaged updates, but uses a sort of a more flexible, robust mechanism which harsh will go into a little bit more detail. Further, if a transaction fails for any reason, and there are lots of reasons why it could fail that are valid and also some that would be not as valid but still relevant.
If it fails, that error is preserved and that transaction state is noted, it's failed and it can be retried. And we'll see that in the demo. Two each respective application should own the processes and experiences where that app is focused. So if you choose to integrate, that means inventory and financials are owned by the finance and operations applications. Work order management is owned by field service. Effectively, this allows each application to focus on its core, its respective core competency, which we think makes for a one plus one equals three scenario higher value.
By having these two things combined together, for example, in field service we have some inventory capabilities. They're pretty good. They're not as robust as what supply chain offers, and we think we would prefer to focus on the rest of the service flow and leave inventory and financials to finance and operations, while field service focuses on work order management and the service process. Third, we think keeping highly transactional data in close record for record sync between systems is a tough model. Trying to sync every inventory, transaction and warehouse counts between systems is not a recipe for success. We've used some clever approaches to try to avoid that.
We'll talk a little bit about that in the demo as well. So primary data that's required for each system to function like accounts and products and warehouses is a great fit for dual write. We utilize dual write to drive a number of things across between the systems so that we can talk the same, speak the same, make sure that both finance and operations applications and field service are speaking the same language. So for a quick architecture review, there are a number of tables we're keeping in sync through dual write.
The list is long in our documentation. When we create a work order, we link that work order through a virtual lookup to a project in FNL. We'll see all this in the demo and we create a sub project. We did consider integrating with sales orders, but instead, after bunch of research discussion with partners and customers, we decided project was the clear right path.
And the real idea here is for a number of reasons. One, we think this serves both internal and external field service scenarios. So providing service to my customers, or providing service inside my organization, or of course organizations that do both. And we think this offers a great deal of benefits in terms of financial accounting maturity.
From there, parts and labor are added, and field service which creates project journals, and those are ultimately posted once the parts and labor are consumed, which have an impact on pricing and cost and general ledgers inventory by virtue of using the correct journals. We'll see all of that in the demo in a minute. Then we expose that data in field service as if it were native data, but directly using virtual tables.
So show that as well. Let me take just a second to talk a little bit about how we're a little bit more depth of how we're aligning transactions. If you create a work order product that'll either land in one of two ways, it'll either land as an item journal and an associated line, or an expense journal with an associated line. So if it's a work order product with a product that is of type inventory in field service, if you're familiar with field service, that lands as an item journal, if it's a project, sorry, work order product of type, product of type, non inventory that'll land as an expense journal, and then work order services land as hours journals in the project. I think I'll also just take 1 second to talk about there are a number of integrations that are out there now, and I want to make sure we are all on the same page in terms of which ones to use when first, obviously today we're talking about this new integration pattern which is field service aligning with finance and operations applications and work orders in this new pattern online with projects we do use, we do utilize dual write, but it is not entirely dual write based. So that's the one we're talking about.
Today we'll talk about that, obviously in a lot more detail. There are two other patterns that exist already. So there's one that's been out there for a while that uses dual write integration. It's been for a couple of years at least.
It encompasses some of the field service concepts by aligning things like assets and purchase orders and a number of relevant tables in support of those scenarios. That pattern is complementary to the pattern, to the integration we're talking about today. So that pattern, this dual right pattern, all the dual right maps, shouldn't adversely impact the integration we're discussing today. And further, of course, as I mentioned earlier, there are a number of, of dual write patterns that we, that are dual write mappings that we use in the, in the new pattern, in the new integration. And some of those were built originally for these integrations, like warehouse as an example, so that one exists and is complementary. You can use both, or you don't have to, you don't have to use the other one.
Of course you have to use the dual write maps that we documented in the, in our documentation for this integration to work, but otherwise you don't have to use the entirety of that existing integration using dual write. There is another integration that is much older, uses data integrator and it integrates work orders and sales orders that's been in use for a number of years. I want to say, I don't know, seven or so, something like that. It's a solution that integrates field service and is built on top of an integration solution. That's prospect. Prospect.
It has a prospect cache integration solution that's also built on the data integrator. The prospect to cache solution using data integrator is not compatible with dual write. Those solutions don't work with dual write, so that older integration using beta integrator is perfectly fine to use. We have lots of customers still using it today, but it is not compatible with the new integration and couldn't be used in conjunction with it. I just wanted to highlight that in case there was any I know there are a couple of them out there and make sure we're all talking about the same thing. With that, let me jump into demo.
Let me start by talking about enablement. All these steps are detailed out in our documentation, but we have a number of dual array maps that need to be assured on the list is all in our docs. Feel free to review that in more detail. Then you would need to enable the feature in FNo. Let me just show that over here.
So in Fno waited just a little too long. Let the session end in FNo. If you go to feature management and we can search for this, we'll see the feature which is enable field service integration. So you need to enable this feature then in field service, in field service settings. And here, this is an.org
that doesn't have this enabled. So I can show you the install button. We have this install button, so you trigger this, it'll install an additional solution which allow once that's installed, brings in with a bunch of logic and metadata, and then you would need to actually once it's installed, it looks like this, the install button is gone and it would be in a disabled state, you would enable it. And we think it's something that we wanted to be able to enable or disable to allow for some testing as organizations take this up and sort of better understand how it works. One other key setting, so that would be enablement, enable your maps, you enable the feature in FNo, you enable the feature in FS which install the package and enable one other setting which is worth talking about for a moment is this setting here. This setting drives supposed when we post the product, that sort of the transactions that we create, the journals that we create in F and O.
So there are two patterns. So first we have when products or service services are used. So this setting dictates that we would as soon as the product is created, so work order, product or service, I should say is created, we would create that transaction, that journal and line in f and o. But if it's not used in FS, it would just be in an unposted state in FNO. And we'll see this in a moment in the demo. And then as soon as I set it to used in field service with this strategy in play, that would be set to post it right away.
We think this strategy makes a lot of sense for organizations that have longer running work orders. So if your work order is going to be sort of in progress for more than a day, a couple days, your organization can decide what your appetite is for that. You would probably not want to wait a very long time for your financial and inventory, the impact of your field service operations to have an impact on your system of record, for finance and for inventory data. So that's this pattern. The other pattern is when work orders post it. So what this one means is effectively you go through your work order process, you create your products and services like normal.
None of that would show up in your finance and operations applications until the whole work order is set to posted. And we think this makes more sense in scenarios where you have short running work orders where they are likely all completed in progress and completed in the same day, which is a lot of our customers have that pattern. But of course you can use either pattern and make sense for your organization.
So that's a setting here that you'll want to make sure you're setting this up correctly for your scenario. For the sake of our demo, I think this is a little bit more of an interesting one. So we'll see these things show up right away. Right, let me then show inventory. So I want to point out two things. So with this, I'm back to the this is the where I don't have the integration installed.
I just want to point out a couple of things. If you're familiar with field service, this is what the sort of navigation looks like when the integration is not installed. This is native field service. We're showing the native field service inventory.
So you see this product inventory table and transfers and adjustments and rmas, rtvs, et cetera. So these are all things that are sort of functions that are against field service, native inventory. I highlight all of that because when this integration is enabled, we're suppressing that build service is no longer the system record for inventory. So we suppress our native inventory, some of those functions that are specific to our native inventory functionality, and we then expose the inventory as it this is inventory that is coming directly from f and O, so we aren't doing anything to keep these things in alignment. This is, we're using virtual tables to directly read the data from finance operations applications.
So this is a direct read and it's just exposed as if it's native data in field service. So this is a slight difference component of the integration as you transact in field service using item journals that will have a direct impact on inventory levels. Of course, because you're using journals that are native to finance, to supply chain, you'll see those have a direct impact on the inventory levels. With that, actually, let's create some work orders. Create one. Let's create a new work order.
And I'll point out a couple of things while we do this. I'm going to select an account and I'm going to pick this service account. So if you're familiar with f and O, you're likely aware of the concept of company or legal entity in f and O that is pervasive and a vital concept in finance and operations applications in field service natively.
This isn't a concept that we have any real there's not a concept in field service natively. So what happens when this integration is turned on is that of course this needs to be something we become very aware of and are doing our best to set up the transactions for success so that they'll succeed in landing correctly in FNO. When I pick this service account, what I want to highlight is this service account has an associated company, USMF, that will drive the filtering on a number of related tables in field service on the work order. Once this is selected, one of those tables is this new lookup here for the FNO project. I can look for a project that I want to transact in.
And this is filtering to show only USMF projects. And it's ship filtering to show projects specifically either for that customer or which have no customer. And that's likely more true for internal projects. But there are other scenarios where that could make sense.
But we are filtering to show this here. This is filtered based on the service account you select. There are a number of other fields that are filtered.
I'll show that in a moment. So we'll push save here and what I'll point out. So this is going to trigger creation of our, we've associated with the project. This will trigger creation of our sub project. So if we look back over here, we should see that that transaction is created so it's creating and still unsynced, and then we'll see that goes through. Now I'm showing this because I want to show, I want to highlight how this works in the integration.
We don't think that this table, which is in settings, if you navigate into settings and go to fieldstrip fno transactions, you can monitor all of these transactions. We think this is a really useful table and gets back to that concept of making sure that no transactions disappear. So of course we expect 99.999% of the time all these things are going through successfully. But of course if they don't, for some reason, if we scroll down further, I think we'll find some failed ones. We could see that they might fail and they might fail for reasons that are valid.
Like in this case, I think there wasn't any inventory available. Or they could fail for reasons that are. Maybe one of these systems is down. And of course that's terrible. But the worst thing we could do is then create some problems later on where all those transactions aren't and than recoverable. So all you would, you could go back here and trigger those transactions.
So let's go ahead and add. I'm going to add an incident type. In this case I'm adding this audio install or audio system install. It's going to add two products and a service so we can see those journals get created. I'll push save while that's saving and creating some transactions. Let me just talk about what incident type.
Incident type has always been super important, continues to be super important. What it does is obviously creates. It templatizes the type of work you do, where it adds products and services and characteristics and tasks. All of that is great. But what's really important to think about in this scenario is now when this integration is active, you probably want to organize these on a company basis.
So your products and services within a given incident type should be associated with the company where you'll use it. And we think this may happen naturally. Of course, if your organization, if your company's segregation of your businesses is a long functional lines, this is why fire system business and this is my electronic security business. Those instances are likely to be different. And of course it's probably not going to be a problem. Your products and services are likely to align against company lines anyway.
But even if it has to be an unnatural motion, it's important to make sure that these are organized correctly. Because what these products and services that get added are you also company specific? So if we look back over here, we should see that we've had a handful of transactions, so these are all related to work order number 30. We can see that there are some creates and some updates because of how that transaction and that works where we've created those lines successfully. So if I go over here and let me sort of change this list.
So now I'm looking at all the projects in USMF. And so here's the one that we just created, subproject number eight, which is related to work order number 30. And just to point this out, so there's an active speaker, which is an inventory product. This has a product variant.
I'll talk about that. I'll show that in a second. We also have this journal for locally sourced expense. So this would be an expense product and this would be an hour's journal. And we'll show all that.
So if we look, let me point out a couple things on this, on the item journal. So if we look at this item, we'll see it's the active speaker, we look at the lines, we'll see it's used the right item number for that product and we'll also see that it sees the right variant. So this variant is the color is color black.
There's another variant for this product that's white. So by using the right product in field service, which is us sort of taking, you know, taking one step further beyond the dual write forward products and, and release products and product variants, you were creating these products correctly in the item journal. So this is a product color black variant. And in addition, we also respect, so this product happens to be configured that it requires location. So if you're familiar with storage dimensions nf they have various levels of granularity, site, warehouse and location.
We are making sure that if the product is configured to require location, that we also do that. So what we'll see here is we require once it's set to use. But you'll see here that we're showing this location field. This is conditionally shown only when it's required and it's enforced when we set it to used. So that's really important to highlight that if I made an update to the quantity. So let's say I'm going to use three of them.
So let's save that. And if I look back at my journal line, let me just go over here before it sinks through, so we can see quantity is one. So if I give it a second, or I can check here the state of the transaction.
Again, not expecting amity to babysit these things normally, but here it's synced. So now if I refresh this, obviously it's now quantity three, because of course that's what the integration is doing. We're updating that. Let's take another look over at our expense journal. So we created that locally sourced consumables expense line.
So what you'll notice on this journal is that this is a category based transaction. So categories and items are different. If you're familiar with SNL, you probably already are super familiar with this concept. In FS, everything is product based. So all of our transactions use a product that's map. Let's ignore that for the moment.
Everything's product based. This is the product in FS. Everything is using a product. So if I create a work order product that is a type non inventory, that's still a product in FS. If I create a work order service, that's again, still a product in FS, even though it's a service line. In F and Oddheaddeh, the expense, expense journals and lines, expense lines and hours journals and lines are category based transactions.
There's no category concepts in field service. So we bridge that concept by associating the product. So if we look at this product. We associate this product with a, this is another of the, it's a virtual table lookup and it's filtered. So if I look here, we see this project category lookup. So I associate this to a project category, and that transaction then can be created correctly in terms of how FNL expects it.
So we're using this concept to map between the project. Sorry. That the product type transactions field service and the category type transactions at FNO.
So this is the category that's been populated over here, which is great. I'll also highlight. Let me just show one thing.
So this is back at the journal level. This is unposted. So we can see that's unposted. So if I go back to my line here for this locally sourced consumables expense, if I set it to used, that, of course updates the transaction to set it to use. That's now consumed effectively.
We want to bill for this. So what we'll see if we give that a minute to go across, or I can double check it, make sure it's gone across processing, and then syncede. This is all asynchronous.
Sync failed. It's actually a valid error. This is saying that f and o doesn't want this to go through because the budget's on balance and so you have to do something on the fno side and then you retrigger this transaction. Well, what I wanted to show was this expense would change to posted when I set it to used. But for now, we'll skip that part.
So we create the work order, the product, and we set it to use, it would have posted this line. So that would have gone through. And then. Yeah, the other thing worth noting, uh, but before I pass it over to harsh. So the last thing we're noting is.
So in this particular strategy, and it can happen in other strategies with back here at this, this setting, uh, if I set these things, if I set the work order to post it and I have some lines that are not, uh, not used, we clean those up from the snow side. So you don't have all of these unposted journals and lines sitting there after the work order set to posted. So this can happen in both scenarios, but is, of course, much more common in the scenario where you're sending these things across immediately in the f and o. In the case of the other transaction, which waits until things are posted, it is theoretically possible that you might sort of switch between states. Like the work order can move back from posted into a transactable state infield service.
So we do a number of things to handle that correctly from an FNO perspective. So just to highlight that we are doing our best to one create these things correctly in FNO to transact or update them as appropriate based on the things that happen in field service and then to clear them correctly when it makes sense. Of course, once they're posted, we're not clearing them, but if they haven't been posted, we don't leave those out there in an unposted state after the work order is posted. With that, see, I've walked through how work orders are created, how that creates subprojects, how work order products and services create journals and journal lines, how those in theory get posted. I think with that I'll pass over to Harshen who could talk a bit more about extensibility guidance so we can augment this sort of integration pattern to support hopefully any customer scenario. Thank you Jason. Hi everyone, my name is Harsh Birla.
I wanted to talk about the extensibility opportunities with this integration. Although we strive to provide the best possible out of the box experience for our customers, we understand that each business is unique. As a result, you may need to extend Dynamics 365 application to support that specific requirements of your business, right? Therefore, this integration also supports extensibility. Since there are both apps involved, developers can leverage Dynamics 365 extension patterns in x, for example creating chain of command, creating event handlers in x.
Similarly, for field service side, developers can leverage power platform dataverse extension use maker portal to create new fields, to create new lookups, to add validation roles, to create plugins, etcetera. We have recently introduced unified development environment, what we call it UDA. This kind of environment supports development across both application finance and operation and field service. So you can consider a single environment with both the apps installed in this and you have ability to basically configure your development tools, for example visual studio, and create a single package for deployment. We are not covering UDe in detail in this TechTalk.
We have provided links to various resources around UDe so you can deploy unified development environment in your power platform admin center and configure the dev tools to basically do extension and have the ability to debug it in UD environment. Since it involves both apps, it's important to consider application lifecycle management which is alm. You may be still using finance and operations build pipeline. So if you are making changes that supports this integration, you need to consider deploying FNO X packages as well as you need to basically move the solutions right from PAC platform from one environment to another right.
So we need to consider the ALM best practices. Consider both the apps, both the apps deployment at the same time. Last but not the least is environment lifecycle management which is emerald since it's connected.
Environment disintegration leverages dual write and virtual entities. Therefore, it becomes important that we maintain the healthy environment lifecycle best practices. For example, if you need to move database from production to sandbox, we need to consider both the database movement. We need to follow the best practices which are described for dual right EM management. We are not covering this in detail because they are standard practices used in a connected environment when you install dual write, so there are enough resources available.
However, we wanted to talk about some of the extensibility pattern and the technical design of this integration. Let's deep dive into technical design. As Jason mentioned that this integration leverages the standard out of the box platform capabilities of dual right and finance and operations virtual entity. However, in the demo you have seen when we create a work order, it gets into a processing queue and then it basically creates the project infinance and operation or sub project infinite operations. So let's talk about the technical design. There are both apps, field service app and finance and operations app described here.
There are native field service tables, for example work order and work order product table whenever there is an event in terms of, let's say creating a work order with finance and operation project, it basically captures that event. Create the queue record in field service FNO integration transaction table this table doesn't hold any data. It holds the transaction id and this queue. You have the ability to basically monitor and basically you have ability to reprocess some of these field messages as well. Once the record is there in the queue, it is unsynchronized status and there is data words asynchronous job that runs behind the scene which actually reads the record in this queue and then make Odata call to finance and operations there is a data entity called field service transaction entity. This entity has this Odata actions like process project async and process journal async based on the nature of transaction.
If it is, if it is project creation, or if it is general creation, the calls made to a respective odata action and then this odata action basically pass the information to finance and operations batch reliable framework. There are controller and service classes in x. They are responsible to create the project or project journals by calling all the business logic and validation inference and operations, and ultimately inserting data into native finance and operations table so that you can view project table projects and inventory journals and then the posting is being triggered, right? So since it's basically using all the x reliable async batch framework, it doesn't really impact the interactive user's performance. As such, we wanted to also showcase some of the examples, so we can think of three different kind of examples and we have provided published these examples on GitHub. We'll share the link in the resource section as well. You can take the inspiration from these examples, but make your own judgment.
Hey, what is the right way to do extension for this integration? You have ability to raise extension requests as well from lcs if there are not enough work points available. So let's consider an example wherein you need to create a new custom field in field service work order table and then you need to move and stored that value in finance and operations on the sub project, right? So I'll quickly move to my environment where I can create a new new work order. I have already selected the service account. Let me select the finance and operations project which is 197 and subproject is blank and this is new extended field, right? So this is extension field custom field and I will go ahead and save this work order.
It should create a record in the queue which is unsynchronized and once the dataverse background job picks up it will do a Finns and operations odata call to create the sub project. So let's save this. In the meantime it is processing. So let's take a look at finance and operations so we don't see the project yet.
However, what we have done is we have created new custom field in field service work order table which is called extension number, added the field on the form as well as we have added this field inference and operations and write the code to basically update the sub project. So we are still waiting for this to come in. So this is the new recorder and we see the new extended field gets moved along once the project gets created in finance and operations. This is one example. Second example could be you want to create a new custom field in field service work order product table and similarly you want to move this field to the journals. It can be item journal, it can be expense journal, or it can be an r journal.
So let's create a workout product and you can create data types like a string or even lookups, right? And then map it accordingly. So let's take an estimated quantity of three, select the warehouse and location. For this demo we have created a new field called and let's say billing comment and I will save this work on product. So I have already created a new extended field and saving the work product record refresh it.
It is currently an estimated state so I will change it to used. And once it is used, uh, it is going to create the uh, item journal infinite operations against the sub project. I think the approach is to basically uh, create a field in invent general crons table in finance and operations as well as on platform side. We are creating a new column, uh, in work order product table and was the integration runs. It should create a new, it should create the item journal and post it.
So it's already posted and I created this line item for two quantity and we have created this field, right? So you can see the new custom value gets moved along on the journal as well. Third scenario could be where you want to basically move the value from finance and operations back to field service, right? So consider a scenario in work order product table. You want this value to be moved from finance and operations.
So let's say in FNO, sales tax group is determined based on the item setup. And once the journal line gets created, the sales tax group is assigned on the journal line and it gets posted. Now you want to move and you want to have the ability to view that sales tax group in field service work order product table. And similarly there can be any kind of computation that FNO is doing during posting and you want to expose the data back to field service. So that is also possible.
So what we have done here is in this example, sales tax group is already available. It's the standard out of the box field and there is a data entity available. That means we can enable this sales tax group as a virtual entity. Finance and operations virtual entity.
So I have enabled this sales tax group virtual entity. If you can see sales tax group, this is virtual entity directly coming. And then I have added a lookup from sales tax group. Now since our data model is ready, we need to write the code to push the value of the guid of that virtual table. So in this example, if you look at it, since we have already posted this transaction, now the logic is written so that it can push the value of the virtual entity guid back to field service.
Therefore, you see as part of this integration was the general is created journal is posted, it is updating the status of it is updating the status of the record as well as updating the value in free service. These examples are available in GitHub are published. You can take inspiration with these example. However, you need to decide what is the right way to do extension using already established extension pattern. Now we wanted to talk about implementation best practices since this integration relies on different aspects of our platform capabilities.
So we wanted to make sure you are aware of some of these best practices and you can follow these in your implementation. First and foremost is dual write since this integration leverages dual write. If you are evaluating this integration or in the process of deploying it, it is important to understand that integration is highly dependent on dual write primarily for the mapping of master tables and it is kind of a foundation block and we have provided a list of dollar table maps that needs to be enabled so that customers product contact warehouse information currencies. These can move from field service and FNO or vice versa. Second thing is category based on action. As you heard Jason mentioned earlier, there is a conceptual gap between field service and FNO in that field service doesn't have concept of product category.
To bridge this gap between Dynamics application, we recommend that you capture the project category value that field service can use for work order, product and service transactions. Since this value is not populated by dual write, you should either update this value on the products that are synced over from the dual right or create a specific products for a use as a proxy for transactions against a category in non inventory and service scenario. We have documented this as well so that you can read through next is project selection as you saw in the demo, an FNO project value is required on the field service work order to enable this transaction integration to FNO.
By default, the project lookup field on the work order form has to be populated manually. It is likely that your business will have unique business logic that can be used to automate the population of the project value on the work order. You need to analyze what is the right way to populate the value of the project. Next is worker alignment the field service integration with FNO application extend Dynamics 365 human resource integration to include the concept of the worker to the field service bookable resources.
This allows the worker to be captured on the work order, product and service transaction. If you enable this worker integration, it is important to note that the worker field is not filtered by default and does not assume workers are eligible to perform work on the related project or whether a worker eligible for a for having a work order scheduled to them as a best practices organization might consider using security roles and business unit or introduce resource characteristics to ensure workers are only scheduled for relevant work order. Security rule there are a couple of security rules created or provided as part of this integration experience.
You can assign these inference and operations. Specifically, you can assign these security roles to the users. However, this integration relies on virtual tables and dual rights, so all the security rules, best practices related to virtual entities and dual light are applicable here as well. There are certain limitations that we have published a list of limitations on our documentation.
Just wanted to hydrate that this for example, this integration currently supports on Microsoft managed FNO sandbox environment as well as on unified development environment. If you are using lcs cloud hosted environment then you won't be able to enable this feature. And next is project operations, resource and nothing non stock integration doesn't allow field service integration to work with the same legal entity that are enabled for resource and non stock integrated scenario.
Currently that's the limitation. However, you can work in the same environment for other legal entities. Virtual entities currently do not support offline mode within field service mobile app. That is why it may be important to set up the defaulting logic for sites and locations so that transactions don't get blocked when a frontline worker attempts to create a work better product or service using mobile app while offline. So these are some of the limitations that we wanted to talk about and we have curated a list of resources.
There are different TechTalks on unified admin experience, there are different TechTalks on FNO extensibility. There are different documentation available on dual write virtual entities and some of the example or the extensibility that we have talked about. So these will help you to basically make that foundation and building blocks to enable this integration. We are excited to provide this first party integration capabilities between both the apps in field service and finance and operations, and we hope that it will help our customers and partners to adopt and evangelize and we can bring the real business value to our customers.
With that said, I think we can take. We have still four minutes. Any other questions? Guido, do you see that we can cover? Yes, there was a question at the beginning which was regarding using equipment on the work order province and wanting to track the history of where the equipment has been. Did we have suggestions for I don't know how that would be workable? Yeah, I mean, I'll sort of add this, something we thought about in the past week. I think this is very closely related to this concept of serialized inventory.
This particular piece of inventory maybe came off the shelf, was installed here, went back to the depot and was refurbished and then installed somewhere else. We think this is of course a real use case at the moment. Today we don't have a good solution for it out of the box, either in native field service or with this integration.
But we think tracking dimensions. So you realize inventory is probably the way to go and moves us towards solving this scenario, but it is not in place with this integration. Okay. There were a number of questions regarding pricing as well. I believe you may have answered most of those. Yeah. I mean, obviously, I think we probably answered them. But worth highlighting here for recording's sake, which is we recognize that right now what we're doing, which is FS drives pricing costs into FNO, with the caveat that item journals, we don't drive costs into f and o because, of course, SCM has, well, I guess both finance and supply chain have strong opinions on how the cost gets calculated.
So we recognize that we'd love to have some other strategies as options, and at the moment, those are not supported out of the box. And we think there may be ways organizations might extend it to do that, but that's not something we are currently supporting. We do hope to eventually support some additional patterns that allow the price to be driven by finance and operations and brought back to field service. Final topic that has come up is assets and asset integration. Yeah, I think the shortest answer is, of course, we have a dual right pattern for assets, which is the EAM assets, like they call maintenance assets. I think the question was around, specifically around fixed assets, which I don't recall off the top of my head if EAM, I don't remember how they drive alignment between fixed assets and maintenance assets.
So I guess maybe we can take that question in more detail to the VBA channel and if there's some more details you wanted to talk about there. But short answer is, we have a dual rate pattern today between the assets and field service and asset city. If you're looking for something else, we'd love to better understand that. Yeah, it's good that you bring up the rewatch channel as we're at top of the hour and running out of time here.
Of course. Thank you very much, everybody, for all your questions. Of course, in the Q&A panel, we could only give pretty brief answers.
If you, if you wanted to follow up on those questions, please feel free to use our channel to engage with us, and we'll make sure to get back to you on your questions. Thanks all.
2024-08-13 08:13
