I'm looking for cross site lookup values from one site to another site in SharePoint Online. is it possible to achieve this? if yes, could you please guide me the steps to perform this task.
It is not possible to use list items values from one site as options in lookup column in a list on a different site, without any customization. I think what you could be looking for is term management and manage metadata columns. Term store management is something you create for a tenant level. In a very simple explanation you may think of it as a place to create global and hierarchical dictionaries made of terms and groups. Then in SharePoint list or library you may add a manage metadata column that will allow the users to pick values from a specified termstore. You may create this kind of column on any list and any site as terms are available on tenant level.
Please look more into the concept here -> https://learn.microsoft.com/en-us/sharepoint/managed-metadata
And here is an example how to create a manage metadata column -> https://support.microsoft.com/en-us/office/create-a-managed-metadata-column-8fad9e35-a618-4400-b3c7-46f02785d27f
I hope this will be of any help.
Update
within term store you may create a nested structure grouping terms and then when user selects the value he may select from terms in this structure so it may be like a kind of cascading choice but presented differently. I am not sure if it will meet your needs
Related
I have worked on Azure Search service previously where I created an indexer directly on a SQL DB in the Azure Portal.
Now I have a use-case where I would want to ingest from multiple data sources each having different data schema. Assume these data sources to be 3 search APIs of X,Y,Z teams. All of them take search term and gives back results in their own schema. I want my Azure Search Service to be proxy for these so that I have one search API that a user can use to get results from multiple sources, ordered correctly.
How should I go about doing it? I assume that I might have to create a common schema and whenever user searches something, I would call these 3 APIs and get results, map them to a common schema and then index this data in common schema into Azure Search index. Finally, call this Azure Search API to give back the results to the caller.
I would appreciate any help! If I can get hold of a better documentation for doing this work, that will be great as well.
Your assumption is correct. You can work with 3 different indexes and fire queries against them, or you can try to combine all of them in the same index. The benefit of the second approach is a better way to implement ordering / paging as all the information will be stored in the same index.
It really depends on what you mean by ordered correctly. Should team X be able to see results from teams Y and Z? The only way you can get ranked results like this is to maintain a single index with a common schema containing data from all teams.
One potential pitfall with this approach is conflicts in the schema. For example if one team requires a field to be of a specific datatype or use a specific analyzer, while another team has different requirements. We do this in our indexes, but with some carefully selected common fields and then dedicated fields prefixed according to our own naming convention to avoid conflicts.
One thing to consider is the need to reset the index. If you need to add, change or remove fields you will have to delete the index and create it again with a new schema. If you have a common index and team X needs to add a new property, you would need to reset (delete and create) the common index which affects all teams.
So, creating separate indexes per team has its benefits. Each team can have their own schema without risk of conflicts and they can reset their index without affecting the other teams.
I am setting up a large (2000+ records) "task tracking register" using a SharePoint List, and intend to use Powerapps as the UI.
As you would imagine there numerous drop drown fields in the list which I would like to use as a filter within the Powerapp, but being that these are "Complex" fields, they are non-delegatable.
I'm lead to believe that I can avoid this by creating additional Columns in the SharePoint list that use a Flow that populates them with plain text based on the Drop-down selected.
This is a bit of pain, so I'd like to limit the quantity of these helper columns as much as possible.
Can anyone advise if a Powerapps Gallery will initially filter the results being returned using the delegateable functions first, and then perform the non-delegatable search functions on those items, or whether the inclusion of a non-delgatable search criteria means that the whole query is performed in a non-delegatable manner?
i.e.
Filter 3000 records down to 800 using delegatable search, then perform the additional filtering of those 800 on the app for the non-delegatable search criteria.
I understand that it may be possible to do this via loading the initial filtered results into a collection within the app and potentially filtering that list, but have read some conflicting information as to the efficacy of this method, so not such if this is the route I should take.
Delegation can be a challenge. Here are some methods for handling it:
Users rarely need more than a few dozen records at any time in a mobile app. Try to use delegable queries to create a Collection locally. From there, its lightning fast.
If you MUST pull in all 3k+ of your records, here's my favorite hack. Collect chunks of your data source then combine into a single collection.
If you want the function to scale (and the user's wait time) you can determine the first and last ID to dynamically build a function.
Good luck!
I need to have multiple MSRP based on customer location. I am planning to add "location" field in "product-option" which will be available for each product, so an SKU will be available for each product based on location. And I don't want the user to choose this option, it should be the default selected.
Is this a right way to do that, or please suggest a better way to achieve it.
I think it depends on how ephemeral your pricing considerations are. If the pricing will be changing on a regular basis based on a rate table (or something like that), you can utilize the dynamic pricing service, which will allow you to programmatically alter the pricing based on whatever business rules you deem important. Start with registering your own DynamicSkuPricingFilter (i.e. extend AbstractDynamicSkuPricingFilter - see DefaultDynamicSkuPricingFilter) and provide whatever attributes are important for your pricing determination. Then, register your own implementation of DynamicSkuPricingService (see DefaultDynamicSkuPricingServiceImpl) to return the correct pricing. I would also consider extending DiscreteOrderItemImpl with location information so you have a record in the cart of the associated location.
Otherwise, if you want to have more permanent data structure and explicit admin user intent about maintaining this pricing, then I would suggest a new entity structure that relates a simple location and price to your default sku. You should be able to naturally maintain this in the admin using #AdminPresentation annotations. For example, consider a new admin annotated collection of "LocationPrice" entities off of a custom extension of SkuImpl. Then, you would still use the dynamic pricing suggestion from above, but you would be basing your determination off of this maintained data. I think this is more natural in the framework than trying to use options and multiple skus.
Finally, I assume you're using the community version of Broadleaf. We generally fulfill this type of requirement using our commercial PriceList module, which is more feature rich.
The scenario is that I have a Projects list and there are a bunch of different SPFieldUser fields associated to it. I have another list representing the Project's Logbook (it contains a bunch of data about different milestones of the project). The relationship is like this: (1 project list item : 1 logbook list).
I have to store some metadata in a logbook's list item that points to a specific user, stored in Project's list item. For that I have to create a choice field which represents different SPFieldUser fields from the project's list.
The question is which is optimal way of representing such a structure?
I can just hard-code a choice option for every SPFieldUser in a Projects list, but then when I have to reference this data in a code, I'll have to somehow transform the choice's value into internal name of the associated project's field.
I can also create a lookup of those fields and this way, accessing it is easy. I can show the Title to user and have the internal name stored in a lookup.
I was also thinking about defining some kind of custom FieldType, but I feel like it would require far more work than an of the other methods.
So which method do I choose? Can someone probably suggest a better way?
Lets check out your options one by one in terms of efforts and scalability.
1 Hardconding option : High efforts [Not at all recommended]
- Column needs to be updated when new user joins or user leaves the
company.
- Once format of data is specified its difficult to change. [e.g. FirstName+Lastname or Empid]
Highly recommended OOTB option : very low efforts
Configurable [Please check if you can change format of user data once added as lookup column.]
Custom column type will take coding efforts.
My recommendation is 2nd OOTB option. If you find some flaws in 2nd option let us know we can look for soultion.
This is a simple requirement: I want to add a set of strings to Accounts in Dynamics 2011. The string are external IDs for other systems. All the strings should be unique accross all entities.
The only way I can see to do this is define the strings as entities (say 'ExternalCode') and set up a 1:N reslationship between Account and ExternalCode, but this seems incredibly overweight. Also, defining as an entity insists thhat I give the 'ExternalCode' a name, which it obviously doesn't have.
What's the best way to implement this?
Thank you
Ryan
It may seem overweight, but think about entities as if it were tables. Would you create a second table inside MS SQL? If so, then you should create another entity. CRM is very well optimized so I wouldn't worry about this additional overhead.
Alternatively, you could always carry the GUID in the other system.
How are these unique references entering your CRM system. Are you importing the data from each of the external systems? If so I assume the references are unique in the external system? Once imported you want to make sure that any of these references are not duplicated?
Additionally, how many strings are we talking about here? If it is a small number then it would make sense to just define attributes to manage them and check for duplicates in one of the following ways:-
1) Some javascript could be used to make an oData query to confirm the 'uniqueness' of your external reference number before the record is commited. (But, this is not sufficient is records will be created programmatically in the system also).
2) A plug-in which fires on pre-create to again query the system for other records which match the same unique reference numbers and handles the event of a match accordingly.
However, if there are many of them then it may make more sense to define a separate entity as you say and then as above you could associate a new 'reference record' with the entity via a plug-in, but again, check if the record already exists and then either handle an exception or merely associate with an existing record if that is appropriate.
I think they key is what you want to do if you do find a duplicate and how these records are going to be created in the system (e.g. via UI or programmatically or potentially both).
Happy to provide some more assistance if you have some more details.