G’day @Joshua Milisits thanks so much for sharing your thoughts here!
Happy to hear you’re enjoying the new calculations fields so far and extending the calculations engine beyond numbered question types and to support something like date fields is definitely something we want to pursue in the future.
Absolutely love your idea around the different fields for different product as well this will certainly get the minds at SC HQ thinking !
+1 for time based calculations and product list.
We could also use for recording cooking and cooling times of cooked food.
These are CCPs in our HACCP plan and atypically are in any cooked food HACCP plan. Would be very beneficial to have the ability to calculate time.
I also agree that time calculations could be useful.
Regarding product lists, we use the SC API to populate 11 global response sets per site, one of which is our products and another is our finished goods (as there can be more than one SKU per product item). What’s unusual is when you use the API, you can populate both a “label” and a “short_label.” We have yet to get an answer as to what Short Label is used for in SafetyCulture. If you build global response sets manually in the platform, there is no place for anything but the front-facing label. It would make sense if short label was the ID stored behind the scenes. That would give the user the front-facing visible label to select from but the short label in the dataset. Unfortunately, it doesn’t seem to be working that way.
The idea above regarding having additional information tied to items in the list that we could use to pre-populate questions in the inspection is interesting. I’d have to think about how we might use that.
Hi @Joshua Milisits
I see that @Paddy Bell’s already addressed the first point there.
For the second point, I do believe our Assets feature is worth exploring – see our support article on What are assets? As of now, it’s definitely possible to characterise each asset (or SKU/Product) with all the details you’ve outlined there, such as weight and size dimensions. And each template can be edited to have a question that asks users to select the relevant asset, which would then link the inspection to the asset’s profile. The one thing that you’ve mentioned which isn’t possible right now is the prefilling, but it’s definitely been requested before, and our team plan to explore this area in 2024 The alternative is what Corey mentioned regarding the use of global response sets, where you can use the API to automatically create/update/remove products as responses in global response sets.
@Corey to answer your question about `label` and `short_label` for global response set API, the short label is actually a legacy feature that’s no longer applicable – but as you’ve pointed out here, it’s not great that it’s still a required string when creating responses, so let me bring this to our team to see if we can retire that field once and for all – appreciate you keeping us honest
Hi @Joshua Milisits
I see that @Paddy Bell’s already addressed the first point there.
For the second point, I do believe our Assets feature is worth exploring – see our support article on What are assets? As of now, it’s definitely possible to characterise each asset (or SKU/Product) with all the details you’ve outlined there, such as weight and size dimensions. And each template can be edited to have a question that asks users to select the relevant asset, which would then link the inspection to the asset’s profile. The one thing that you’ve mentioned which isn’t possible right now is the prefilling, but it’s definitely been requested before, and our team plan to explore this area in 2024 The alternative is what Corey mentioned regarding the use of global response sets, where you can use the API to automatically create/update/remove products as responses in global response sets.
@Corey to answer your question about `label` and `short_label` for global response set API, the short label is actually a legacy feature that’s no longer applicable – but as you’ve pointed out here, it’s not great that it’s still a required string when creating responses, so let me bring this to our team to see if we can retire that field once and for all – appreciate you keeping us honest
Hi Jack,
Thanks heaps for this information. I was able to get all our products in the system under the Assets Register and creating an Asset Type called “Finished Products” and adding in custom fields linked to each asset, which worked really well with the bulk upload feature. However as you mentioned above ,outside of this, selecting the asses only works on the Title Page of the Template and no other information such as “Display Name” or any other Custom Fields pull across into the template once the Asset has been selected.
I think once this feature becomes available it will be really useful! As i work for a large Pie manufacturer, every day we do weight checks, colour checks and temperature checks on products (Assets) as they come out of the oven. Being able to select "Beef Pie" from the assets list, and have automatically display the (Detail Fields) Unique Code, Display Name, Photo, Weight and Temperature Restrictions would be amazing! If those displayed fields (Detail Fields) could have logic behind them built into other questions to flag responses that did not meet the Detail Fields preset values linked to the Assets Profile that would be even more incredible Then i would create response questions asking to fill in actual Weights, Temperatures and photo of the product. and then the system would cross reference this data based off what is already loaded on that Asset profile (excluding the photo as image recognition might be stretching it) Haha.
Anyways this was just some thoughts as i believe a lot of people would benefit from this and not just people in the food industry. I do look forward to seeing how this feature evolves in the future. Hopefully sooner rather than later :)
Cheers,
Josh
No worries @Joshua Milisits! Stay tuned for this indeed
Something else that might be of interest, which might come in the near future, is the report layout feature. Currently, in inspection reports, you can only see the “Unique ID”, “Type”, and “Name” of an asset. We want to support customising what asset details to display in inspection reports, so if you have weight and temperature restrictions as fields in an asset, they can be shown in reports :)
@Corey to answer your question about `label` and `short_label` for global response set API, the short label is actually a legacy feature that’s no longer applicable – but as you’ve pointed out here, it’s not great that it’s still a required string when creating responses, so let me bring this to our team to see if we can retire that field once and for all – appreciate you keeping us honest
Rather than retiring, it would be great to use it and add it to the web platform too. It’s pretty common in other systems to have a visible value and a background ID which is stored (or both stored but one displayed more prominently). Our IT department rep has told me short_label is how it sorts, but I proved them wrong that sorting is all in the order you upload the values to the response set. Then we were stuck wondering what it did.
@Corey to answer your question about `label` and `short_label` for global response set API, the short label is actually a legacy feature that’s no longer applicable – but as you’ve pointed out here, it’s not great that it’s still a required string when creating responses, so let me bring this to our team to see if we can retire that field once and for all – appreciate you keeping us honest
Rather than retiring, it would be great to use it and add it to the web platform too. It’s pretty common in other systems to have a visible value and a background ID which is stored (or both stored but one displayed more prominently). Our IT department rep has told me short_label is how it sorts, but I proved them wrong that sorting is all in the order you upload the values to the response set. Then we were stuck wondering what it did.
I’m inclined to agree @Corey! We definitely dropped the ball here by removing `short_label` support in the product experience but leaving it in place via the public API still
There’s definitely an opportunity for us to implement this properly in the future, but for now, I think given that the field doesn’t actually do anything to shape the product experience, we might still go ahead with retiring/hiding OR, at a minimum, make it not required when using the API endpoint.
Appreciate your thoughts, as always
Under consideration→Not planned