cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
5by5T
Frequent Visitor

Tracking Production Status

Hey all, 

 

Bit of a data structure question for all you nerds out there. I'm using CDS to build a barcode scanner application that tracks batches throughout a production process. At each stage of the process, the worker will scan the machine and then scan the batch; the app will store the data of what stage (or machine) the batch is at and what time etc. 

How is best to structure the data for each stage? Should I make a status field (option set) for each stage and then they could just use auditing to see when and where it went through the process? 
Or should I set up an entity that is meant to just hold activity for all stages?

 

Thanks!

2 ACCEPTED SOLUTIONS

Accepted Solutions
DavidJennaway
Solution Supplier
Solution Supplier

I would go with an separate entity for each stage, for a few reasons:

  • It gives you flexibility if you ever need to add extra stages at a later date. If you had an option set per stage, you'd need to add extra fields when you add a stage, but with a separate entity you wouldn't need to
  • Also more flexibility if you decide you need to store additional information with each stage; with a separate entity you'd only need to add one field
  • Using a separate entity allows you to store information if the process every needs to repeat a stage, as you'd have a separate record each time you go through a stage

One possible drawback of a separate entity is that some reporting can be a bit more complex - e.g. if you want to compare values between stages, as the fetch XML query language doesn't allow expressions across records, though you can normally workaround this

View solution in original post

EricRegnier
Super User
Super User

Hi @5by5T,

Great question! Entity modelling is a big debate and one of the most important CDS/D365 design decision in my opinion. Again, don't think there's no right/wrong answer and it depends on so many things. I would need to know more about your requirements to provide more guidance, but my first thought (with the following assumptions) was a single entity with a record create per stage.

Assumptions:

  1. The fields and data captured between the stages are similar. 
  2. The security requirements are similar. Users have the same privileges to access the data between the stages.
  3. The stage entity is likely related to a parent entity (i.e Work Order) where the parent contains the common info (like customer, product, etc) and the stage contains the process info like stage, user that scanned, location, timestamp, etc.

The stage entity would have a "Stage" field (lookup or optionset) that identifies which stage the scanned occurred. So every time a user scans, a new record is created where you capture the info and link it to your parent entity (i.e Work Order). From the Work Order or a dashboard/view, you can see the progress by listing all the related stages in a single subgrid/list. Key benefits of a single entity are:

  1. Better user experience. Easier for users to search, query and understand the where the data sits (entity model)
  2. Can display data in a single out-of-the-box grid
  3. Facilitates maintenance;
    1. Wouldn't need to update every entity. For ex: if a new field is required for every stage, then you'll need to create that field (and ensure it has the same name and data type) for every entity and update the forms and views, etc for every entity
    2. Less privileges to configure, etc

For more complex scenarios with lots of fields and lots of record, here's a good guidance: https://crmtipoftheday.com/1280/to-split-or-not-to-split-that-is-the-question/

Hope this helps! 

View solution in original post

2 REPLIES 2
DavidJennaway
Solution Supplier
Solution Supplier

I would go with an separate entity for each stage, for a few reasons:

  • It gives you flexibility if you ever need to add extra stages at a later date. If you had an option set per stage, you'd need to add extra fields when you add a stage, but with a separate entity you wouldn't need to
  • Also more flexibility if you decide you need to store additional information with each stage; with a separate entity you'd only need to add one field
  • Using a separate entity allows you to store information if the process every needs to repeat a stage, as you'd have a separate record each time you go through a stage

One possible drawback of a separate entity is that some reporting can be a bit more complex - e.g. if you want to compare values between stages, as the fetch XML query language doesn't allow expressions across records, though you can normally workaround this

EricRegnier
Super User
Super User

Hi @5by5T,

Great question! Entity modelling is a big debate and one of the most important CDS/D365 design decision in my opinion. Again, don't think there's no right/wrong answer and it depends on so many things. I would need to know more about your requirements to provide more guidance, but my first thought (with the following assumptions) was a single entity with a record create per stage.

Assumptions:

  1. The fields and data captured between the stages are similar. 
  2. The security requirements are similar. Users have the same privileges to access the data between the stages.
  3. The stage entity is likely related to a parent entity (i.e Work Order) where the parent contains the common info (like customer, product, etc) and the stage contains the process info like stage, user that scanned, location, timestamp, etc.

The stage entity would have a "Stage" field (lookup or optionset) that identifies which stage the scanned occurred. So every time a user scans, a new record is created where you capture the info and link it to your parent entity (i.e Work Order). From the Work Order or a dashboard/view, you can see the progress by listing all the related stages in a single subgrid/list. Key benefits of a single entity are:

  1. Better user experience. Easier for users to search, query and understand the where the data sits (entity model)
  2. Can display data in a single out-of-the-box grid
  3. Facilitates maintenance;
    1. Wouldn't need to update every entity. For ex: if a new field is required for every stage, then you'll need to create that field (and ensure it has the same name and data type) for every entity and update the forms and views, etc for every entity
    2. Less privileges to configure, etc

For more complex scenarios with lots of fields and lots of record, here's a good guidance: https://crmtipoftheday.com/1280/to-split-or-not-to-split-that-is-the-question/

Hope this helps! 

Helpful resources

Announcements
Power Apps News & Annoucements carousel

Power Apps News & Announcements

Keep up to date with current events and community announcements in the Power Apps community.

Power Apps Community Blog Carousel

Power Apps Community Blog

Check out the latest Community Blog from the community!

Users online (3,888)