latest Post

Half Baked Access Teams

One feature I think that gets under used is "Access Teams". When wanting to collaborate on a record with users in other Business Units users always seem to opt for setting the owner of the record to a team or sharing the record with an individual. I prefer access teams to sharing a record as its easier to see exactly who else can see the record directly on the form.

 Anyway while working with access team templates I came across an issue I had not come across before probably due to the limited use and due to how we manage our solutions between environments.

As you will know to create an access team you have  to add a sub grid to the form and  choose “users” as the entity, set default view to "Associated Record Team Members" and finally choose an “access team template” (Assuming you have enabled the entity for access teams and setup the template in security settings).



However, to my suprise access team templates  cannot be added to a  solution.   (At the time of writing). This means when  pushing a solution between organisations if the access team template does not exist the sub grid will be unable to set the "Team Template" associated with it. (See below screenshot)






You may say well just go into your other organisation and create the access team template and modify the form component and re-attach it to the template. However, due to exporting all of our customisations from the base environment to other environments as managed means that: 

1.) Not following best pratices  (in my opinion)
We shouldn't really modify  components in a managed state in the default solution. (I understand some ISV allow this via managed properties but I feel if possible these changes should always be done in the unmanaged solution and exported.

2.) Change  can be potentially overwritten 
As we are editing a managed component in the default solution there is the potential that at a later point the change would be lost on import if the user ticks to "Overwrite unmanaged Customisations". We find we sometimes we have to do this to force through some changes if they have previously been edited in the default solution.


Solution 

Even manually creating the access team template in the other organisation prior to import of the solution would still result in the team template being blank and have to be updated manaully due to it referencing a different guid. 

To fix I ended up having to create an SSIS package using KingwaySoft connector. The package simply queried one environment for the access team template and recreated it in the second environment with the exact same guid as the first. This then meant when I pushed the solutions between the environments the access team template could be successfully applied. I used SSIS for quickness but I could quite of easily created the access team template using custom code via the SDK or WEB API calls. 

It does seem a little bit of on oversight though that you can reference something in a solution component that the solution has the potential to know nothing about when exported to another environment. 

At the very least I would  of expected the solution to  warn me on export that the solution will fail if the other environment doesn't already have that Access Team Template component already. 

Looking on the community there seems to be a few others having the same issues relating back over 5 years. I have logged this as a user voice  so if this is affecting you too, please vote up.




Recommended Posts × +

1 comments:

  1. Access is a term used to describe the time between a team recording and their hit is made. Each team has different requirements ranging from 30 secs to 3 minutes. This is just a quick introduction of what access is. You can fix the sidewalk for the building material. Teams are always in contention to be placed on the downloadable calendars and are then circulated to the other teams that are on the same team.

    ReplyDelete